OSDev.org

The Place to Start for Operating System Developers
It is currently Mon Mar 27, 2017 8:41 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Kernel testing.
PostPosted: Sun Aug 28, 2016 1:53 pm 
Offline
Member
Member

Joined: Fri Jun 17, 2016 11:29 pm
Posts: 49
Hey.
How do you guys test your kernels? how does the linux kernel get tested?

I've noticed there is a lack of good frameworks for testing kernels(integration / unittests), and thinking about writing a library for testing kernels.

Any thoughts?(Good idea, bad idea, there are plenty, SHITTY IDEA GTFO..)


Top
 Profile  
 
 Post subject: Re: Kernel testing.
PostPosted: Sun Aug 28, 2016 2:33 pm 
Offline
Member
Member

Joined: Sat Mar 01, 2014 2:59 pm
Posts: 1061
That is fairly kernel-specific. You probably couldn't write a testing framework that is appropriate for even a small minority of kernels.

_________________
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing


Top
 Profile  
 
 Post subject: Re: Kernel testing.
PostPosted: Sun Aug 28, 2016 4:42 pm 
Offline
Member
Member

Joined: Fri Aug 19, 2016 10:28 pm
Posts: 43
VM vendors verify the OS and software behavior under virtualization. I believe using scripted testing. If someone could chip in and explain the basic techniques they use, it may be applicable.

I say, schedule, memory management, etc, will require instrumentation. But the tests are not responsibility of the framework. The test environment is.

IMO, it would be best done with a VM solution and pseudo-device for communication with the guest OS and such. It would be a big undertaking.


Top
 Profile  
 
 Post subject: Re: Kernel testing.
PostPosted: Mon Aug 29, 2016 11:11 am 
Offline
Member
Member

Joined: Thu Jan 29, 2009 9:13 am
Posts: 93
A test verifies a given functionality under a specified load. A suit of tests could just be a directory of applications that test the individual pieces(unit tests), then test collections of functionalities. Once the pieces are working together create tests that use very large numbers of things to make your kernel scale(apps ask for more memory than the system has, fork bomb handling, etc). Later on when you encounter bugs you can just create a program that replicates that fail condition and code around it. This scheme allows automatic batch testing to any machine you can boot from ,Virtual or Physical. To poke into the kernel with this method to do performance testing or memory leak detection you would need a list of privileged API calls to get that information. This will make your test suite kernel specific, but any framework capable of knowing where a kernels scheduler is or when the kernel is leaking memory is already too kernel specific to be portable anyway.


Top
 Profile  
 
 Post subject: Re: Kernel testing.
PostPosted: Mon Aug 29, 2016 3:39 pm 
Offline
Member
Member

Joined: Sat Nov 07, 2015 3:12 pm
Posts: 127
You can test your kernel if it is designed to be testable. Which means you have " seams points" in it , in order to isolate tested parts of your OS from the rest of it.
First , you need to identify what kind of parts of your kernel to be tested. An OS is usually a kernel, drivers, daemons ( or services ) , low level libraries (abi, libc), and user land apps. you will want to test each part while it is isolated.

You can, if you want your os to be tested in Linux of example
+ create a Abi library of your os which use Linux syscalls. that way you can test your user land apps in Linux.
+ Create a wrapper for your kernel drivers which makes them usable from fuse/ kernel module loading .. that way you can test any driver of your os.
+ For the kernel alone , just make some dummy drivers / user land apps which will test the lowest level. You can make them output in the serial port, run your kernel with fake drivers / usrtland apps in qemu with no GUI option.


Top
 Profile  
 
 Post subject: Re: Kernel testing.
PostPosted: Sun Sep 04, 2016 8:54 pm 
Offline
Member
Member
User avatar

Joined: Tue Dec 25, 2007 6:03 am
Posts: 692
Location: Perth, Western Australia
I've used two techniques to test my kernels/OSes

The first is to run isolated modules as userland binaries (e.g. the network stack with a "nic" that is just a unix socket to the test harness). This gives nice module and unit testing support, but requires that your code be easy to isolate from the rest of the kernel (which may not be easy, depending on the structure).

The second used a python wrapper around qemu and booted the system, and waited for specific log messages on the serial port (taking screenshots as it went). This has the upside of covering the entire system, and if written well can emulate human access patterns (e.g. moving the mouse, and making typing mistakes) - but is computationally expensive.

_________________
Kernel Development, It's the brain surgery of programming.
Acess2 OS (c) | Tifflin OS (rust) | mrustc - Rust compiler
Currently Working on: mrustc


Top
 Profile  
 
 Post subject: Re: Kernel testing.
PostPosted: Sun Jan 01, 2017 4:10 am 
Offline
Member
Member

Joined: Sun Oct 09, 2016 4:38 am
Posts: 275
I first compile my code immediately to get the myos.bin file, then use qemu to run it using the -kernel option.

_________________
Developing TRIODIUM OS. Or call it Dixium if you want. It doesn't matter.

https://github.com/NunoLava1998/DixiumOS


Top
 Profile  
 
 Post subject: Re: Kernel testing.
PostPosted: Sun Jan 01, 2017 5:25 am 
Offline
Member
Member
User avatar

Joined: Sun Dec 25, 2016 1:54 am
Posts: 181
thepowersgang wrote:
The first is to run isolated modules as userland binaries .


The BSD Rump Kernel concept essentially replaced the syscall mechanism with an RPC mechanism allowing instrumentation, file i/o (debug logging), etc... for things as complex as whole filesystem drivers...

The principle of Rump Kernels really took off when the boilerplate sycall/rpc mechanism was complete. After that you could do anything from testing to performance measurement to even remote device drivers running on other operating systems....

good stuff

_________________
Plagiarize. Plagiarize. Let not one line escape thine eyes...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group