Flux OS - test request, looking for devs
- NickJohnson
- Member
- Posts: 1249
- Joined: Tue Mar 24, 2009 8:11 pm
- Location: Sunnyvale, California
Flux OS - test request, looking for devs
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!
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!
Re: Flux OS - test request, looking for devs
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?
Code: Select all
<Error>
<Code>AccessDenied</Code>
<Message>Access Denied</Message>
<RequestId>F83DF8175063B907</RequestId>
−
<HostId>
Hijq4h/200bZYzq+CJlxlRN3orPu1KnXbW01NoaU510BBR0MxhCYNyGfT9cXByj6
</HostId>
</Error>
Also, is there some place I can go to like a wiki to get information about Flux other than source?
- NickJohnson
- Member
- Posts: 1249
- Joined: Tue Mar 24, 2009 8:11 pm
- Location: Sunnyvale, California
Re: Flux OS - test request, looking for devs
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.
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.
Re: Flux OS - test request, looking for devs
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..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.
And tell me when it's reuploaded, I'd like to try this out.
Re: Flux OS - test request, looking for devs
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.
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.
- NickJohnson
- Member
- Posts: 1249
- Joined: Tue Mar 24, 2009 8:11 pm
- Location: Sunnyvale, California
Re: Flux OS - test request, looking for devs
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).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.
- NickJohnson
- Member
- Posts: 1249
- Joined: Tue Mar 24, 2009 8:11 pm
- Location: Sunnyvale, California
Re: Flux OS - test request, looking for devs
Okay, the image link is fixed. You can use the same one, or this one.
Re: Flux OS - test request, looking for devs
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.NickJohnson wrote:I do see what you're saying, but I also disagree.
Re: Flux OS - test request, looking for devs
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 .
When the chance of succeeding is 99%, there is still a 50% chance of that success happening.
- NickJohnson
- Member
- Posts: 1249
- Joined: Tue Mar 24, 2009 8:11 pm
- Location: Sunnyvale, California
Re: Flux OS - test request, looking for devs
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.
Re: Flux OS - test request, looking for devs
This is a project that looks promising. Well commented, very small, all works good... this is a good start!
"Open source seems to embrace the dark side of human nature." - Ville Turjanmaa
Re: Flux OS - test request, looking for devs
I tested it a bit in qemu, I'll test it on some real hardware a bit later..
Re: Flux OS - test request, looking for devs
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
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
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
Re: Flux OS - test request, looking for devs
Awesome, now he can scratch that system off his lists.clange wrote:1. Hydrogen (unknown)
Serious, how can you NOT know any details about your systems? if you honestly do not, why the hell are you on this forum?
Re: Flux OS - test request, looking for devs
Brynet-Inc wrote:Awesome, now he can scratch that system off his lists.clange wrote:1. Hydrogen (unknown)
clange wrote:I can provide more info about the machines if you need it.
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.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?
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.