Slashdot Mirror


Fiasco Microkernel Version 1.0 Released

'lonzo writes "Version 1.0 Fiasco, a GPL re-implementation of the L4 microkernel has recently been released. This microkernel is designed to be a flexible hardware abstraction layer rather than YetAnotherCloneOfUnix. Its 'mechanism not policy' design allows far more opportunities for *ghasp* innovation than any of the Unix clones. It also provides people with an alternative to the macrokernel design of Linux. Get your copy here. Linux has already been ported to this OS, get it here, and another port."

3 of 29 comments (clear)

  1. Re:huh? by Anonymous Coward · · Score: 1, Interesting

    It does use the Linux kernel, silly. It's running in user space on top of L4, alongside other L4 apps. So Linux apps run in user-user-space. Hey, maybe if L4 was ported to L4, apps would run in user-user-user-...-space.

  2. Re:Hooray for C++! by Pseudonym · · Score: 3, Interesting
    There are two high level languages suitable for writing operating systems: C and Ada.

    A sensible person would stop reading here, but I'm not sensible. The most suitable language for writing a given OS depends highly on internal (e.g. features) and external (e.g. linkability) constraints. We used to have operating systems written in assembler, PL/I and Oberon. Nowadays we have boot PROMs written in Forth. All of these decisions were certainly justifiable at the time.

    Incidentally, I used to say pretty much the same things that you do about C++, until I wrote my first nontrivial application in C++. Nowadays I'm not a C++ zealot, but I'd far rather hack in C++ than in C any day.

    It doesn't offer anything over a well written C program. If you write two identical programs on the same level as an OS in both C and C++, you'll end up with a lot of lines of code being about the same. Going through the extra trouble (and compilation overhead) involved in C++ isn't worth the bother when 99% of the code is the same.

    Pull up your Linux source and have a look at fs/pipe.c. Scroll down to do_pipe. Stare at the code for a moment. All those gotos didn't write themselves.

    Now scroll up to the file_operations structs. What you're looking at is a bunch of virtual function tables.

    This type of code may not be much shorter in the equivalent C++, but it's going to be a lot more than 1% different, and the difference is almost all going to be in maintainability, which is far more precious than number of lines of code.

    Factually, C++ is the most used programming language there is, but to a first approximation, all of this code is for Windows, and I don't count Windows.

    I don't know where you've been. There are lot more job placements for Unix C++ programmers than Unix C programmers.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  3. Good idea, questionable implementation by Anonymous Coward · · Score: 1, Interesting

    Ever try to hack linux? It is cryptic, convoluted, bloated, pretty much awful code. No good docs for it, and even if there were good docs for it they are quickly out of date because the core linux contributors all get together and change everything every few months. There is only one way to figure out how to do stuff and that is to study the awful, cryptic code. The newsgroups + mailing lists don't work, people don't answer the deep technical question you ask.

    So here's the idea: Have a tiny micro kernel, and all device drivers are user processes that are independent of each other. So someone could rewrite the ide system without it impacting anything. Each system would be a small standalone tree, easy to pick up, understand, and add to. Hardware makers would like it because they wouldn't have to really know LINUX (monolithic kernel and all the details of it) to write their device driver. They'd just need to know the interface to the micro-kernel. Driver development would progress at an unheard of pace. And this is critical, if all the drivers are made to be linux compatible, all the linux codebase would work.

    Anyway sounds really good. So I go download fiasco and try digging for documentation. How would I access the pci device list to find my device so I could implement a driver for it? How does dma work? All I can find is that it is an implementation of threads and a memory manager with virtual/protected memory so processes (threads?) can't harm each other. I find fiasco is l4 compatible (what is L4?) I find on l4 page there is a postscript spec sheet (why not pdf?) I gunzip the ps file and gs (ghostscript) it to view it, and am told

    Can't find (or open) initialization file (gs_ll3.ps)

    Can't find any overall description of how it all works, the theory. I see a big list of function calls. No introduction, nothing to aid in the learning process.

    Here's my point: No matter how wonderful a new piece of code is, it is useless to *everyone* unless they know how to use it. If those guys want to go anywhere with this code they'll stop working on the code and start working on a primer for wouldbe contributors. Make it easy to pick up and all that hard work, all those wish list items, will magically just happen.