Nikolaos S. Karastathis of Wikinerds has interviewed Marcus Brinkmann, one of the main Hurd developers. It’s an insightful interview into Marcus offering a look at how he got started hacking in general and on the Hurd in particular, his version of the recent history of Hurd development, and where he thinks the Hurd is going (hint: away from Mach and towards L4). The presentations from the Hurd developers’ mini-Symposium at FOSDEM 2005 makes for good supplemental reading.
Hurd Developer Marcus Brinkmann Interviewed
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Brinkmann is always one of my most favorite hackers.
Remind me again why they’re porting to L4? Do they actually want to take another ten years before releasing? Or will something new and shiny come along and Hurd will have to be ported to that. In the meantime, it still will lack driver support…
It’s fun to see that the complaints about Hurd/Mach are just the same issues that Linus pointed out in the now classic Torvalds/Tannenbaum flame.
The fact is that Hurd will never go anywhere, it will forever be a toy OS. That doesn’t imply its bad, but it’s about time they just clearly assume that.
But I thought the general consensus was that wherever the Hurd/L4 was going, it was going there far too slowly to be of much relevance to most users – which is a bit of a shame really considering the work people like Marcus are doing.
They use Pistacho (BSD licensed) and not Fiasco (GPL licensed).
Macrokernels are faster to design, and have speed, but they sacrifice flexibility and security. Microkernels require more thought, planning and time to implement, but they provide tremendous flexibility, secruity and reliability.
Torvalds didn’t expect to make an OS that would become as big as it has and Tannenbaum knew that if the OS did succeed it would be better if it were microkernel in architecture, in the long run that would be much better.
We have machines that run in the GHz and how many of those CPU cycles are actually used for something? Modern desktops have 512MB RAM even though the average user just goes to web sites and plays MP3s or DVDs. How much of those resources are actually used?
A microkernel based OS offers a tremendous number of benefits and these days we have the CPU cycles and low-latency-high-bandwidth memory that the “slowdowns” become a wash. Maybe 5-10 years ago on a 25 MHz machine the performance hits hurt, but now days, we have more brute force than we can usually use. We also understand OS architecture better and we can experiment much more easily with tools like QEMU, VMWare, Xen and so on.
Typically, when you introduce a layer of abstraction, you introduce a slowdown. What you gain in exchange is flexibility and cleanliness in code, portability and so on. Linux is (now) a portable operating system — if it were written exclusively (for example) to run on the x86 architecture, it could use all sorts of tricks and features to extract even more performance (i.e. the x86’s ring levels and intricate protection schemes). A result of the portability goal is that the kernel authors have to design their software more generically, even if the underlying hardware has some capabilities which they have to forsake for cross-platform uniformity.
I think that you should spend some time looking into the advantages of a microkernel. If you want an example of a blazingly fast microkernel OS, take a look at QNX.
Finally, the intelligent always try to learn something from someone else’s effort. Even if the HURD/L4 doesn’t succeed as a modern desktop OS, the knowledge they uncover can be used, even for macrokernel OSes.
A microkernel based OS offers a tremendous number of benefits and these days we have the CPU cycles and low-latency-high-bandwidth memory that the “slowdowns” become a wash. Maybe 5-10 years ago on a 25 MHz machine the performance hits hurt, but now days, we have more brute force than we can usually use.
Apparently you live in a totally different world than mine. Today’s computers are already too slow, anything that makes that worse is just not going to be acceptable. And no, its no going to get any better.
I’m looking forward for (even more) “modularized” linux-like kernels with clear separation of mechanism/policies.
I don’t think microkernels are right. Just look at the link – “we realized that having fs’s in userspace don’t allows us to do good memory management”. Hardware is like that – microkernels may have sense in future’s hardware, not in today’s, IMHO. From what I understand, what they’re doing is conceptually wrong – moving all the “memory management” to task. It sounds like nanokernels, but it doesn’t looks like a good idea. The whole purpose of “virtual memory” is that it should be, well, “virtual”, ie: transparent to apps. If you’re going to move that to apps….well, virtual memory was not designed for that, IMHO.
And moving “paging” decisions to apps won’t improve performance. What you actually care about is about _system_ performance, not “app performance”. Hurd developers seem to think that moving mm decisions to apps will improve performance – I don’t think it’ll be the case, performance is a system wide characteristic, when you’re under load you may want to pause temporally all taks expect one just to allow it progress instead of trashing like mad. How will they implement that, if their mm decisions are separate? Process would have to cooperate, and you know, they are NOT going to cooperate…
Reasons to switch from Mach to L4 (some might be better then others):
1. Hurd doesn’t need all of what Mach provides.
2. GnuMach has old Linux 2.0 drivers, with OSKit Mach you can get Linux 2.2 drivers and FreeBSD (don’t know the version) drivers but with L4 you get OSKit drivers without work and can even get Linux 2.4 drivers without work.
3. Hurd was supposed to be portable from microkernel to microkernel, right now it isn’t, and porting it to L4 might make it portable.
4. Gnu must maintain GnuMach for Hurd, most Mach implementations I can think of are old, or propitiatory or both. L4 has lots o’ Free Software implementations that are being maintained.
5. L4 will probably provide a really nice speed boost.
6. The developers what to do it.
Much like RISC/CISC, today we have PISC, the P is for pragmatic. Take the G5 (PPC970?) from IBM, in an interview, it was mentioned how “convenience” instructions made a lot of sense. Kernel “weight” should take a similar approach. Though if you ask me, I think there should be a few kernels sitting on top of each other, each expanding and extending the previous’ capabilities, such a graduation seems far more natural.
Additionally, computers are not too slow; moreover, they’re slow at inopportune moments. Moreover, this is an issue with development tools and software, there needs to be more work done in enabling developers to optimize their work without having to resort to silly tricks — this goes well beyond playing cat and mouse with the compiler.
L4 seems to be an environment where a whole lot of innovative and fun development could take place. I love the micrekernel approch to architecture.
Audio server, Window server, Graphics sever, Network server, etc. and their corresponding develepment communities, working in each specilized area, and yet converging in ways that don’t bruise the toes of their fellow developers.
Love it.
With the talk of dual-core or quad-core and multi-processor systems, this is idea is ready to fly very elegantly.
GNU/Hurd is not GNU/Linux ! … Now the Debian distro of Hurd is a different thing.
—
Apparently you live in a totally different world than mine. Today’s computers are already too slow, anything that makes that worse is just not going to be acceptable. And no, its no going to get any better.
—
I live in the real world, but I think that it’s you who’s confusing the issue(s). Today’s computers are not slow because of the kernel, they’re slow mainly because of the way applications are constructed — both from the perspective of the software “architect” and the language / tools.
As an example, C++ and Java provide a lot of nice abstractions, but they DO result in slower code. After all, most underlying hardware does not have a concept of an object, so these “abstractions” must be translated into something the hardware does understand. On the other hand, writing in pure ASM (and attempting to make ultimate use of what the hardware can do) may result in a blindly fast program but could take years to develop…software development is a balancing act between features, development time, maintainability and performance.
And if you want to point out, for example, how XP is slow, that doesn’t have to do much with its kernel architecture nearly as much as it does the sloppiness of the people who designed the OS. That implies bad management, poor software architecture and just plain bad implementations.
And, FWIW, the NT/2000/XP architecture is microkernel-ish, drivers can be loaded/unloaded with the OS running. But, as an example of a compromise, the GDI layer was brought into the kernel due to performance concerns.
—
I don’t think microkernels are right. Just look at the link – “we realized that having fs’s in userspace don’t allows us to do good memory management”. Hardware is like that – microkernels may have sense in future’s hardware, not in today’s, IMHO. From what I understand, what they’re doing is conceptually wrong – moving all the “memory management” to task. It sounds like nanokernels, but it doesn’t looks like a good idea. The whole purpose of “virtual memory” is that it should be, well, “virtual”, ie: transparent to apps. If you’re going to move that to apps….well, virtual memory was not designed for that, IMHO.
—
Who says the current paradigms that we’re using are the best ones or the most efficient? At one point in time, people entered programs into computers using punch cards…do we still do that? No, we’ve evolved from that point and technology has evolved to allow better solutions. What’s “right” and “wrong” isn’t clear because we’re *inventing* solutions and creating designs, things aren’t set in stone here. What is undeniable is that a microkernel gives you a lot of flexibility and potentially more reliability compared with a macrokernel.
If you’re going to say that despite that, the performance is low, I suggest you look at an OS like QNX. I don’t mean goto the QNX website, I mean install it on your machine and try it out — even on a 200 MHz processor QNX remains very very responsive and fluid despite a seemingly high-level of multi-tasking.
There are other microkernel OSes, but none that I can suggest that would give you the ability to play and test and feel as much as QNX.
—
And moving “paging” decisions to apps won’t improve performance. What you actually care about is about _system_ performance, not “app performance”. Hurd developers seem to think that moving mm decisions to apps will improve performance – I don’t think it’ll be the case, performance is a system wide characteristic, when you’re under load you may want to pause temporally all taks expect one just to allow it progress instead of trashing like mad. How will they implement that, if their mm decisions are separate? Process would have to cooperate, and you know, they are NOT going to cooperate…
—
Who are you to say what people should and shouldn’t care about? Why do you think that we should all care about “system performance” and not “app performance”? One size does not fit all. In the embedded space, reliability and stability are paramount — even if your system performance is excellent, if it crashes frequently the performance doesn’t matter.
For modern desktop use, the OS performance is at an acceptable level. Could it be better? Yes, it could be. But given how hardware is outpacing software, we happen to be ahead of the game, even if it’s simply because Intel and AMD want to cram more transistors and have them run faster.
The idea here is to look to the future and create frameworks and structures that make it easier and faster both for developers and users. I applaud those who are trying to make a positive difference and are willing to spend their own time to do it.
Sorry, today’s desktop “operating systems” aren’t sold because of the kernel. Take a look at the windows 9x family crap that had been foisted on the world for years.
Given that, servers, niche, and embedded devices are where Linux (or any non MS operating system) can be expected to make the best inroads. And in those markets, performance really does count for a lot.
Double the speed of the processor or amount of memory in an embedded device, and the ramifications go all the way down through physical size, cost, power.
Drop 10% off the pace on a NASA supercomputer, and you’re effectively losing a thousand CPUs worth of computing power.
Spend millions on a big database server with a couple of thousand disks….
You get the idea.
But desktop users, no, they don’t need anything special except to support a wide range of the latest (and not so latest) hardware. Oh, wait.
> They use Pistacho (BSD licensed) and not Fiasco (GPL licensed).
Why do you think that it’s funny?
http://article.gmane.org/gmane.comp.micro-kernel.l4.l4ka.general/71…
how good is hurd/l4 for working with audio and video (in theory). i mean low-latency and real-time requirements…
First: C++ is not slower than C, unless you use its slow features. It’s pay-as-you-go.
To answer the last question: if L4 has a good scheduler, it might be more responsive than Linux for real-time. But in the end, it’s up to the applications to do that. The Unix model isn’t designed for X-Window+Desktop, that’s why sometimes under Linux the mouse might start hanging. The Linux people unfortunately built a workaround that tries to find out what processes are interactive, instead of introducing priorities, like in BeOS. In the end, only the programmer can know what thread should run at which priority.
To the Linux-vs-Microkernel debate: back then Linus was a moron. He hates microkernels all for the wrong reasons. Yes, in Mach messaging is slow; yes, Mach is bloated. But that’s just one implementation. Compared to Linux, other Unices are bloat as well. Does that discredit the monolithic model in Linus’s eyes? Obviously not.
L4+Linux on top of it is only 10% slower than Linux, but has everything running is userspace, so the server could be restarted if it failed; and it’s more secure. Separating the OS into several servers would allow more profiting from SMP hardware, as there are more threads. Maybe it’s time for DragonflyBSD on L4
That said, I would prefer a modular approach to everything in userspace; the speed would be overwhelming (indirect function call instead of trap). The structure would be much better than the Linux mess. If there’s a simple module interface, modules could be loaded *either* in userspace or kernelspace (for untrusted, binary, graphics drivers).
It would be nice to have a kernel that was easily configurable between performance for server operations. I.E. many queued tasks, lots of paging operations, lots of context switching, and emphasis on throughput. Versus performance for desktop operations. I.E. predominantly single user, emphasis on response time.
It would be nice to have a kernel that was easily configurable between the two and didn’t require a recompilation to achieve this.
I think a microkernel architecture takes us closer to more easily configurable kernels, and this could open up a whole new field of interest. How many ways can you “Skin” your kernel? How many interesting parameters can you customize?
That was an interesting read. Thanks for posting.
Can’t wait for GNU/Hurd/L4 to become usable for end-users. Then we can call our OS just plain “GNU”.
You have to assign copyright over to the FSF to be part of the Hurd team.
I hope Stallman is paying as well as Microsoft.
Can’t wait for GNU/Hurd/L4 to become usable for end-users. Then we can call our OS just plain “GNU”.
I bet those computers in the nursing home will be fast enough to handle a microkernel too.
“As an example, C++ and Java provide a lot of nice abstractions, but they DO result in slower code…”
Have you seen this article about L4 and c++ class flattening: http://www.betriebssysteme.org/plos/papers/dannowski.pdf
L4 can be really fast even using C++ slower parts
I live in the real world, but I think that it’s you who’s confusing the issue(s). Today’s computers are not slow because of the kernel, they’re slow mainly because of the way applications are constructed — both from the perspective of the software “architect” and the language / tools.
And since all those apps end up using the kernel, a slow kernel will make it worse.
If you’re going to say that despite that, the performance is low, I suggest you look at an OS like QNX. I don’t mean goto the QNX website, I mean install it on your machine and try it out — even on a 200 MHz processor QNX remains very very responsive and fluid despite a seemingly high-level of multi-tasking.
Windows 95 also behaves very well. Responsivity != performance, in fact what matters in a desktop is reponsivity not performance. Mac OS X feels “faster” despite of being measurabily slower. I should try QNX and see how it behaves with things like “apache workloads”…
But given how hardware is outpacing software
NO, no true. Hardware is not outpacing anything. Today’s hardware is more than 1000x faster than 20 years ago, and I don’t see the apps being significatively “faster”
You have to assign copyright over to the FSF to be part of the Hurd team.
I hope Stallman is paying as well as Microsoft.
The FSF grants back to the original copyright holder the right to use his work as he sees fit; Microsoft does not.
You have to assign copyright over to the FSF to be part of the Hurd team.
Yeah, that’s right. If you’re working on an offical GNU project, they ask that you assign copyright on anything you add, to them. It’s their project.
Of course, if you don’t like that idea, please, by all means, fork the project. We will wish you luck. Really.
Personally, if I was working on a GNU project, I would *want* to assign them copyright. This way, when GPL violations happen, the FSF gets up at bat to protect the software (since they are the copyright holder). Which is quite a bit more convenient than (if FSF was not the exclusive copyright holder) trying to get each individual copyright holder to take time off of work to go defend their copyright.
these questions:
to be microkernel must i necessaryly run services in userland?
what if i get a very modularized kernel, with parts that can be loaded and unloaded? Obviously those parts must have zero fails, or being microkernel i must not to trust in services i run and throw them to userland?
and last, can the extra privilege levels of intel cpus help to make m-kernels faster?
thanx
i don’t know if anyone else knows this… but don’t you think It is a superior design over BSD and Linux?
I mean, I’m mostly a BSD guy but this OS avoids the design flaws the other systems have and is very superior.
Making a monolithic kernel modular doesn’t make it a microkernel. Linux is very modular, but is still a monolithic kernel. Modularizing and Layering are two ways to make monolithic kernels less of a mess. It might be possible to evolve a modular kernel into a microkernel, DragonflyBSD appears to go that way (I don’t know how modular FreeBSD 4.X was before the fork). But the basic idea of a microkernel is that only a small part of the kernel runs in kernel mode. So I would say yes, services must run in userland to make a microkernel.
Yes, HURD has definitely a superior design. There was lots of time spent at the beginning to design the HURD on top of Mach and even more time expanding that design to accommodate L4. I had almost given up on the HURD since there was so much design and no coding going on for a very very long time.
I’m very interested to see how the HURD develops over the next year. There are now enough programmers working on the different part of the HURD that I believe there can finally be a significant amount of work done to get a fully functional and modern HURD out.
I’ve always been a “proof is in the pudding” kind of guy, so I always thought that the so called “advantages” of microkernels was all academic theory. To my knowledge (up until today), there was no successful implementation (open source or commercial) of a microkernel (other than Tannenbaum’s “teaching” OS).
But the annonymous poster in the previous page mentioned QNX. So I checked it out. It turns out that QNX is a successfull microkernel implementation in the embedded market for the past 20 years. It’s been used in cars, military hardware, manufacturing, medical,and all sorts of embedded implementations.
And a few others have hinted that DragonflyBSD is moving towards microkernel design. Is this true?
you may have a deeper look into the embedded/real-time world which mainly use microkernels. Basically, the simpler the kernel, the easier it is to guarantee “real-time-ness”. Also, these kernels are generally not used to run desktop.
and last, can the extra privilege levels of intel cpus help to make m-kernels faster?
Not really. Using more than just ring 0 and ring 3 means you’ve got to start using the segmentation mechanism. On modern x86 CPUs this is slow. On x86-64, segmentation isn’t even available, and you’ve just got ring 0 and ring 3. Even when you do have the extra levels available, you can’t use the fast privelege-level switch instructions (syscall/sysret and sysenter/sysexit). On something like the P4, the older switch mechanisms are an order of magnitude slower than sysenter/sysexit.