Slashdot Mirror
KernelTrap Talks WIth GNU/Hurd Developer Neal Walfield
An Anonymous Coward writes: "One of the GNU/Hurd developers, Neal Walfield, was recently interviewed by KernelTrap. Nice read."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
Strange. Last time we did measurements here (L4Ka), we ended up with 99 cycles on a 450Mhz PIII to send a message from one process to another. If one has communication within a single task the numbers are an order of magnitude lower (i.e., about 15 cycles).
Look - context switches aren't anything special and what's involved is part of an OS design. Giving a static figure like 500 cycles is silly :)
PLan 9 is a whole OS, Hurd is well Hurd. Basically on plan 9 *everything* is a file and accessable as such...even thinks like the mouse coordinates/buffer.
If I understand correctly, the Hurd will, in future be moving to a new microkernel called OSKit-Mach. OSKit-mach is based (as you may guess) on OSKit and OSKit (which is distributed and maintained at the University of Utah) contains Linux device drivers. As you may know, the (vast?) majority of Linux code is actually the device drivers - so most of Linux is now available for users of the Hurd.
So in answer to your point: they have considered the device drivers.
A few people have mentioned trying to merge Linux with the Hurd. For many reasons, this probably won't happen, and would probably detract from some of the advantages the Hurd's design offers.For example, Neal Walfield mentions in the interview that there's a fellow who's succeeded by himself at porting substantially the Hurd to the PowerPC architecture. He took OSFMach from the MkLinux project, modified slightly the four core servers and libc, and had a system capable of running bash, fileutils, and I think some other standard apps. This feat confirms the portability of the Hurd's design, which might not be as easily accomplished with the Linux kernel. I don't know Linux's internal arrangement very well, but I have read comments of Linus's to the effect that kernel development shouldn't be easy. While writing Hurd servers or an implementation of Mach isn't particularly easy, it looks as though the portability and modularity promises of the microkernel advocates may be borne out. In addition, at least one fellow has succeeded at running Lites, the BSD single-server, alongside the Hurd on a machine running Mach. In principle it should be possible to run the MkLinux single server in a similar way atop Mach, perhaps concurrently with the Hurd. This would be similar, according to the Hurd's developers in a recent list discussion, to the virtual server capabilities discussed last week someplace
The Hurd accomplishes this while remaining POSIX compliance, sufficient to make the user experience indistinguishable from standard *nixes. At first my biggest disappointment with the Hurd was that nothing much seemed different. All the standard utilities were there, I got X working (though I don't use kde or gnome -- just windowmaker), and found myself somewhat surprised that most of what I need to do I can get done with my GNU/Hurd machine. This seems to have been accomplished by about ten or so kernel developers plus maybe fifty application porters over a long time; naturally if the user and developer bases were larger, things would be farther along.
My GNU/Hurd system is, however, slow. I haven't done any careful tests, but it feels sluggish at times. File access and network operations are fairly slow, similar operations are noticeably faster with Linux. There's a lot of driver support missing [e.g. no sound
Anyway, it's not quite there yet, but things are coming along, both feature- and performance-wise. It's worth trying out, if you've got a spare pc with a gigabyte of disk or so.
The Linux and Hurd design philosopies seem to be very, very different. Almost incompatible in fact (the architectures that is). So merging the two seems highly doubtful.
But that's ok, they seem to be trying to make the Hurd system API as compatible as possible, so you should be able to chose the flexibility of the Hurd micro-kernel or the performance of the Linux monolithic-kernel and still run most of the same applications. And isn't choice the most important part of the *nix culture?
I've read it, and I think he's wrong. A well-designed modern microkernel OS system should do no more copying than a monolithic kernel does (and it does, say, between user-space and kernel-space).
I suspect that Linus was talking about old systems like Mach, Minix and Windows NT, and not modern systems like QNX, L4 or BeOS. If so, his mistake is understandable.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
flamer...
/will/ load non-GPL compat modules, but it will mark the kernel as tainted.
insmod
read the man page for insmod.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.