OSDev.org

After seven months of work, and a recent name change, I've now finally completed my kernel. Its a microkernel (except for the scheduler and memory manager), with a non-blocking, unqueued, pure message passing IPC system. The system call interface is now stable, and all of the functions work as expected; it also works on all of the hardware I have. The libc is partially done, and I'm working on a driver interface.

So, although I have tested it on Bochs and a couple of real machines, my real hardware is not very varied (all Intel, i686, only three machines), and I want to make sure it is really stable before moving on to driver development. If anyone would test to see if it works on one of their boxes, that would be really nice. It just has a simple test pattern that tests all of the system calls, and a keyboard driver that echoes to the screen. There is an El-Torito cd image here. If the tests finish and you can type stuff onto the screen, that means it is working. You can try to build it from source, but you will have to modify the root Makefile a bit - it also requires using Linux, and generating the floppy image requires using sudo. It will build properly at any optimization level with gcc, at least afaik.

If anyone is interested in the project, it is getting to the point where other developers could help. The kernel source is quite small - about 1500 lines - and reasonably well commented, especially in key areas. The ABI is also fully documented. I mainly need help writing basic drivers (console, disk, and filesystem) - at least enough to be able to bootstrap other drivers and servers. I'm currently working on an interface that will make writing drivers relatively abstract from the system, which should be workable within a couple of weeks. The project is under a very slightly modified ISC license. PM or email (nickbjohnson4224 AT gmail.com) me if you would like to help.

Thanks!

on trying to download the iso I get edit:

Also, is there some place I can go to like a wiki to get information about Flux other than source?

Odd... it works for me, and I'm pretty sure github downloads are public. I'll try and upload it somewhere else though.

The source comments are the main documentation for the implementation of the kernel, but the ABI is documented in detail in docs/abi.txt in the source tree. The first three sections (system calls) are finalized. I don't have a wiki set up, even though I probably should...

Edit: actually, it seems that that error is a result of a recent hiccup in upload service from github - I'll re-upload it later today.

NickJohnson wrote:Odd... it works for me, and I'm pretty sure github downloads are public. I'll try and upload it somewhere else though.

The source comments are the main documentation for the implementation of the kernel, but the ABI is documented in detail in docs/abi.txt in the source tree. The first three sections (system calls) are finalized. I don't have a wiki set up, even though I probably should...

Edit: actually, it seems that that error is a result of a recent hiccup in upload service from github - I'll re-upload it later today.

if your a one man team, you may want to try doing some documentation in TiddlyWiki.. It's just a single html/js file that works as a wiki... You can store quite a bit of data in it too before it gets past the 1M mark where you should consider using something else..

And tell me when it's reuploaded, I'd like to try this out.

It's easy to build yourself from the sources, but running it doesn't show anything interesting. If you're interested in the system, you should better have a look at the documentation and source files.

By the way, Nick, with your method of IPC you're repeating my mistake. Using signals right is difficult if they are supposed to do real work; building up a message queue in user space with signal handlers might be possible, but then you could directly do that in the kernel. From your code it seems that you currently can't even block signals. This means that any program with a useful signal handler is inherently buggy.

Kevin wrote: By the way, Nick, with your method of IPC you're repeating my mistake. Using signals right is difficult if they are supposed to do real work; building up a message queue in user space with signal handlers might be possible, but then you could directly do that in the kernel. From your code it seems that you currently can't even block signals. This means that any program with a useful signal handler is inherently buggy.

I do see what you're saying, but I also disagree. The fatal flaw in many microkernels (like Mach) is the queuing of messages, because of the copying overhead and complexity. The way my signals (which are more like a mix between signals and messages) transfer data is through granted frames of memory, which means there is absolutely no copying overhead. The absence of message queues makes the kernel substantially simpler as well - it doesn't even have a heap, because it doesn't need one. Because the signals are delivered immediately to the target, drivers and other services can respond to events immediately, and signals can also be used for things like fault handling where the non-signal handler context cannot continue: they are even able to simulate threading. And yes, signals can be blocked, using the ctrl system call to set bit 1 (CTRL_SIGNAL).

Okay, the image link is fixed. You can use the same one, or this one.

NickJohnson wrote:I do see what you're saying, but I also disagree.

Of course you are free to disagree with me about any question, but the difference is that I do have a working OS which uses something like signals and you have only something that could become a working OS some time. I'll just let you do, maybe you agree in a year or two.

I gave it a quick test run in VirtualBox and it seems to work just fine. I'm not sure what to do if it's completely initialized though, it spawns some processes, kills them, does some more initialization and says everything passed. Then I can use the keyboard to enter things, but there's not really any response. So if it's supposed to end after the initialization; it works just fine .

Yeah, it's just a test pattern - that constitutes a passed test. I could hack on a shell into the init system, but I would end up throwing it away later. I guess it is kind of boring though.

This is a project that looks promising. Well commented, very small, all works good... this is a good start!

I tested it a bit in qemu, I'll test it on some real hardware a bit later..

Hi

I just tested Flux 0.2 on my test machines. It boots on all three of them without errors

1. Hydrogen (unknown)
2. Helium - Compaq Presario 5838
3. Lithium - IBM ThinkPad A20m

I can provide more info about the machines if you need it.

Good work so far - I'm looking forward to your next versions too

clange

EDIT: fixed spelling

clange wrote:1. Hydrogen (unknown)

Awesome, now he can scratch that system off his lists.

Serious, how can you NOT know any details about your systems? if you honestly do not, why the hell are you on this forum?

Brynet-Inc wrote:

clange wrote:1. Hydrogen (unknown)

Awesome, now he can scratch that system off his lists.

clange wrote:I can provide more info about the machines if you need it.

Brynet-Inc wrote:Serious, how can you NOT know any details about your systems? if you honestly do not, why the hell are you on this forum?

Who said anything about not knowing details. Look how I describe the other machines - by manufacturer name. Take a hint that the first might be some no-name bastard machine.

If you look at Flux (i actually took a brief look at the code - did you???) it doesn't even makes sense to provide detailed description of the hardware. But I offered it anyway.

To answer why I am on this board. Well I have actually implemented my own OS. What are you doing here? Honestly you haven't even implemented a real OS from scratch, why the hell are _you_ on this forum?

clange

EDIT: added a smiley to the last question to reflect the tone I wanted more accuratly.