Slashdot Mirror

← Back to Stories (view on slashdot.org)

Fiasco Microkernel Version 1.0 Released

Posted by timothy on from the freedom-of-choice dept.

'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."

29 comments

  1. Obligatory 'talking out of arse' comment by twilight30 · · Score: 1

    ... Wasn't the L4 microkernel meant to be an alternative, future base for the HURD (currently based on a GNU implementation of Mach, IIRC)? Has Marcus or anyone else had the chance to look at this yet? If so, what do they think?

    --
    ========================================
    Death will come, and will have your eyes
    -- Pavese
    1. Re:Obligatory 'talking out of arse' comment by KayEyeDoubleDee · · Score: 1

      There are already a bunch of L4 implementations out there with varying degrees of availibility and licensing and some using version 4 of L4 ABI are due out soon...

    2. Re:Obligatory 'talking out of arse' comment by paladin_tom · · Score: 1

      Neal H. Walfield is in charge of porting the Hurd to L4. He's waiting for the Pistachio implementation to be released (which is promised to be soon).

      L4 is independent of the Hurd. It's a research-project started by Prof. Jochen Lietdke. It's performance seems to be good (unlike Mach's), and its structure is very different from that of Mach, so the Hurd developers want to port the Hurd to L4.

      --
      #define sig "Every social system runs on the people's belief in it."
  2. I can't believe it! by felipeal · · Score: 3, Funny

    Fiasco Microkernel Version 1.0 Released
    So, Hurd is finally out? WOW!!!

  3. HURD & BBspot: Which OS Are You? by Anonymous Coward · · Score: 0

    If you take this quiz:
    http://bbspot.com/News/2003/01/os_quiz.php
    and skip any or all questions, your personality is diagnosed as:

    "You are GNU/HURD.
    You feel like your life is incomplete.
    If you answer all the questions
    you may get better results."

    Very true.

    1. Re:HURD & BBspot: Which OS Are You? by Anonymous Coward · · Score: 0
      If you take this quiz:
      http://bbspot.com/News/2003/01/os_quiz.php
      and skip any or all questions, your personality is diagnosed as:

      "You are GNU/HURD.

      Yeah, and if yer not the bleedin' Herd, youse a fuckin' Amiga or Win95 (or OS/2 if yer a stupid feck). I had to take the test 10 times, lying like a pregnant unmarried catholic girl, and I still couldn't be fucking Debian. Yeah, I got the bloody Hurdfck by avoiding fucking answering, and the closest I could get to be a fecking fecker was a fecking Red Hat bastard. The test is a fecking joke, it is.

      Nah, shouldn't pe posting after dringin 10 pints of fecking Guinnese, can't even write proper Irisj.
  4. Hooray for C++! by Anonymous Coward · · Score: 1, Insightful

    Finally, a kernel written in a high-level language. This is going to make the nontrivial subsystems like VM and buffer cache MUCH cleanier, easier to debug, and ultimately, easier to improve.

    1. 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});
    2. Re:Hooray for C++! by Pseudonym · · Score: 1

      Fiasco is an L4 microkernel. It doesn't have buffer cache, and it only barely has VM, too.

      One of the good things about L4, though, is that it provides the bare necessities (threads, IPC and address spaces) and the rest is up to you. You can your file system code in whatever language you like.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    3. Re:Hooray for C++! by Anonymous+Brave+Guy · · Score: 1

      Sorry, I can't resist destroying this post point by point.

      [C++] 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.

      You don't know much about how to write C++, do you? Sure, for really low level code, a lot of it will be the same. Then for the higher level parts -- which is still most of an OS -- the C++ should be clearer and more concise. If it's 99% the same as the C, you're doing something wrong.

      For time critical things, you have to break C++'s object oriented model. This might seem like a part of the first reason but it's really a seperate issue. If you're violating the principles your language requires (and C++ lets you do this), then you haven't gained anything by using that language.

      Do you know what the "zero overhead principle" of C++ says? You should read about it before you make such silly claims; try a copy of D&E for a start. Oh, and then try to work out how a language can let you violate the principles it requires. (Of course, C++ doesn't really require you to use OO at all, which is kinda the point.)

      C++ isn't as widely used as C, and thus its maintenance will be less crisp. 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. Furthermore, Microsoft has demonstrated that they want to move away from C++ to C# (I think this is because they want control over the language their stuff is written in). What's going to happen to C++ when 99% of its userbase just disappears? Windows programming has certainly helped to work out the kinks in C++, but without people pounding on it day in and day out, it won't stand for long.

      This just gets better and better.

      • The installed base of C++ on any major platform you care to name is now estimated to exceed that of C. I speak as someone who writes code that runs on more than a dozen OSes every day, from Windows to MacOS to *nix flavours, and several others besides.
      • Microsoft might like the idea of people moving to C#, but it's not stupid. It knows that C++ is here to stay, and that the C++ community values support for some standard features that were previously missing from the Visual C++ compiler. The new version has several significant improvements on previous offerings, and Microsoft currently employs several of the biggest names in the C++ world. That doesn't sound like a company abandoning the language, and I speak as someone who is normally very sceptical of any claimed Microsoft position not supported by direct evidence.

      C++ needs a change soon. This is also true of C. C is thirty years old, and with a few changes here and there, it's still the most relevant language there is, but it drags a lot of weight behind it. Reentrancy issues were fixed by adding reentrant functions (think strtok and strtok_r). When the next issue comes along, are more functions going to be added as well? Because of backwards compatibility, all of this stuff must continute to be supported. C really needs to be replaced with something that has the same functionality, but that can be written with today's machines in mind and backported to older machines, rather than the other way around. C++ has these same issues ahead of it, but it doesn't have the same niche or hardcore userbase C does.

      I just don't know where to start with this. C++ doesn't exactly evolve at the same pace as, say, Java or Python, but whether that's a good thing or a bad thing remains to be seen. How you can claim C has a bigger "hardcore userbase" than C++ is beyond me. I work in fields where these langua

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    4. Re:Hooray for C++! by Anonymous Coward · · Score: 0

      Common Lisp is a much better choice than C++ for Operating Systems development. Of course, that's mainly because C++ is a _stupid_ choice for OS development.

      As a lisp programmer, I would hate to think I was using an OS that used C++ inelegant and brain-damaged single-dispatch OO system, or its crippled templating system, or... etc. etc etc.

      Actually, on a more serious note, there have been OSes written in lisp "all the way down" to assembly language with lisp syntax.

    5. Re:Hooray for C++! by Pseudonym · · Score: 1

      I disagree. Common Lisp is a good choice for some kinds of OS. C++ is a good choice for others.

      One issue with Common Lisp, for example, is that in a loaded OS, resources must be freed as quickly as possible. This means that you have to use a real-time garbage collector. This means extra accounting associated with each object and worse cache performance. This may not be a "problem" in general, but it's an issue to take into account.

      BTW, I'm a functional programmer by design, but I like C++. It's not elegant, that's true. However, I cringe when I see my fellow declarative programmers use the same wrong arguments that I used to use against C++. Then I actually wrote a nontrivial application in C++. C++ is not pretty and it's not pure, but it's very pragmatic, and in the real world of budgets and deadlines, that can be more valuable.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    6. Re:Hooray for C++! by Pseudonym · · Score: 1
      This isn't entirely true, of course, as there will always be some people who don't like or feel the need for things like OO, and who value the simplicity of C. For everyone else, the only remaining credible reason to stick with C over C++ is that its compilers optimize better, so it still has a slight performance edge, and even that gap is closing fast as C++ compiler technology evolves.

      I think this is overstating it just a tad.

      Off the top of my head:

      • Generated code is generally smaller, I believe due to exception handling. This is occasionally important, because old architectures don't die, they just get pushed down the food chain. Yesterday's minicomputer is today's boot sector or tomorrow's smart card.
      • C is sometimes easier to incorporate into legacy systems. Consider, for example, an operating system which needs to be statically linked to the application which it executes. (This is a common scenario in some kinds of embedded system.) If the operating system is written in C, the application had better be written in C too, otherwise your static initialisers won't get run, or exceptions will propagate into the OS.
      • C++ is less binary-compatible than C. This is getting better as ABIs mature, but right now, if you want to distribute a binary-only library, you often need to ship one for each compiler vendor. Or, if you want to allow people to write their own plug-ins, you need to mandate one compiler, or do something else (e.g. make the API C-based or use COM/CORBA/.NET/whatever).

      The optimisation aspect, I think, is a myth. Most C compilers today are actually C++ compilers run with some flag set or with different compilation options. For the same code, you get the same degree of optimisation. I think it's true that it's harder to optimise C++-specific features, but I suspect that you would get better optimisation if you use them than if you try to simulate them in C.

      I pretty much agree with the rest of your post, though.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    7. Re:Hooray for C++! by Anonymous Coward · · Score: 0

      c will have a long life in the embeddedspace. Little chips like the PICs, AVRs, 68H11s, and even the 8051s are programed in c or asm. C++ is just too big for 8k devices. However I remember when people complined that c was too large for the small computers of the time. I mean Hello World could take up 12k! When you just payed $2000 for your 64k CP/M machine with 64k of RAM that seemed just too big. I to will say that I love OOP. I like java better than c++ for ease of coding but c++ is faster than java.
      Ada... I have been hearing about it forever but I still have never seen a good dev system that did not cost a pile of money.
      c and c++ will be around for many years yet. Pascal on the other hand is dieing out even with Delphi still hanging on.

    8. Re:Hooray for C++! by Anonymous+Brave+Guy · · Score: 1
      c will have a long life in the embeddedspace. Little chips like the PICs, AVRs, 68H11s, and even the 8051s are programed in c or asm.

      But mainstream microprocessors are being used more and more often. Economies of scale mean they often cost a comparable amount these days, and clearly they are easier targets for development.

      C++ is just too big for 8k devices.

      That's obviously not true, of course. If you can write for it in C, you can write for it in C++. Just don't use the extra features unless you really need them. And if you do really need them, it's probably more efficient to let your compiler do it behind the scenes than to hand-code an equivalent in C, even neglecting the benefits to development time, code maintenance, etc. that would result as well.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    9. Re:Hooray for C++! by Anonymous Coward · · Score: 0

      Mainstream microprocessors are not being used to replace the small 8 bit chips yet.
      For under $2 you can get an AVR chip with 4k of flash 4 ADC and ain internal clock. No intel/strongarm part is going to touch that for a good long time. You do not need 32bit or even 16 bit cpu's to run a battery charger or even your mp3 player. The cost is also not comparable. An AVR Tiny 11 goes for $2.23 for qty 1 from Digikey. It has IO and a built in clock. No 386+ intel chip can touch it for price. Yes if you compair price per mip the pc class chips are a better deal but you do not need a pc class chip to run a keyboard, battery charger, or a clock radio.

      In the the small embeded space you are dealing with small programs. You can only put so much code into 4k Programs for that will be hundreds of lines not thousands. code maintence is not much of an issue becuase the code is small. It is much easier to debug a 300 line c program than a 30,000 line c++ program.

      There is a large embeded space. Here c++ is useful and you even see Linux in this space. I am working on an embeded project. I am using c for the small mpu that handles the IO and I am using c++ for the main board that handles graphics, networking, user interface, and data storage.
      As to c++ not fiting on the mpus. Yes you can ignore the oop part of c++ and use a c++ compiler but if you never use the ++ part of c++ why use the c++ compiler. Most mpus have there own c compiler or use gcc. I guess you could use g++ but why?

  5. huh? by GigsVT · · Score: 2, Insightful

    How can you call it Linux, if it doesn't use the Linux kernel? Wouldn't it just be Another GNUish System?

    --
    I've had enough abrasive sigs. Kittens are cute and fuzzy.
    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:huh? by Bob+The+Cowboy · · Score: 1

      MMMMMmmmmm..... ganoush.

  6. How metacircularity is useful in practice by yerricde · · Score: 4, Informative

    Hey, maybe if L4 was ported to L4, apps would run in user-user-user-...-space.

    Having a metacircular operating system (one that can run as a user process within another instance of itself) is actually useful, as it allows for virtualizing a machine. This can make server configuration and isolation easier (which is why it's common on mainframes), and it makes kernel debugging a lot easier. Look at User Mode Linux and the new Plex86 for more info.

    --
    Will I retire or break 10K?
  7. This is lovely by 0x0d0a · · Score: 2, Funny

    As far as I can tell, the only practical impact of this is a slap in the face to the HURD developers, who have just been bypassed by yet *another* kernel project...

    --
    May we never see th
    1. Re:This is lovely by Ben+Escoto · · Score: 1

      As far as I can tell, the only practical impact of this is a slap in the face to the HURD developers, who have just been bypassed by yet *another* kernel project...

      This project isn't a competitor to the hurd. The HURD is a bunch of services that need a microkernel to run on top of. So if anything, HURD developers should be happy, because they now have the option of porting their kernel from Mach to the theoretically speedier L4.

  8. Where's the innovation? by Wesley+Felter · · Score: 3, Insightful

    Its 'mechanism not policy' design allows far more opportunities for *ghasp* innovation than any of the Unix clones.

    I agree, but where is it? The L4 crowd, like Mach before them, spent so much time building the microkernel that they haven't built anything interesting on top of it.

    1. Re:Where's the innovation? by Hard_Code · · Score: 1

      nothing interesting?

      --

      It's 10 PM. Do you know if you're un-American?
    2. Re:Where's the innovation? by Wesley+Felter · · Score: 2, Insightful

      OS X uses some Mach code, but it doesn't use a microkernel. And OS X is architecturally not very interesting; it's basically yet another Unix.

    3. Re:Where's the innovation? by Anonymous Coward · · Score: 0
      they haven't built anything interesting on top of it
      Someone's missing the whole point of a modular kernel.
  9. 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.