GNU/Hurd Delayed To Fix Disk Size, Serial I/O Limitations

gregger writes "This Infoworld article indicates that the GNU/Hurd is still waiting to stampede. Evidently they have to switch from the GNU Mach implementation they're using now to OSKit's Mach which will help them support faster serial I/O and larger hard discs. Currently GNU/Hurd will only support somewhere between 1 to 2 GB partitions."

Comments

whoops

[seanw]

The release of a production version of the free GNU operating system (OS) has been delayed beyond the end of the year, as the current development version of the system does not support large disk partitions and high speed serial I/O (input-output), according to Richard Stallman

is it just me, or does it sound like they had it all ready to ship, date planned and everything, and then someone pointed out that it was lacking some major I/O features/performance, and the developers collectively slapped their foreheads and went "oh shit, yeah, we kinda forgot about that one."

like, all this took them by surprise? sucks to forget to implement a couple crucial features, eh?

Thank god they're fixing partition size

[metalhed77]

Does anyone here know why they let the partition size issue languish for so long? Hell, I've had files larger than 1GB (and not porn! go figure). Hard disks have been at the 10 GB mark for years, where it really doesnt' make sense to have 10 partitions. I wish richard luck. On another note, does anyone know how HURD benchmarks against linux?

Re:Thank god they're fixing partition size

[Permission Denied]

The ext2fs server actually mmap()s the partition

This is completely nuts.

I can appreciate that the filesystem driver is a userland process - this means I can write a "filesystem" as a normal userland process (eg, make some things have a filesystem-like interface, so you can do interesting things with databases like make /etc/passwd a directory). This is a cool idea.

However, using mmaping an entire partition is just crazy. This is poor design. What were they thinking?

Are they trying to avoid the system call overhead for seek() calls? This is the only reason I can think of that someone would do this - when you read/write/seek, you have to do a system call for seek(), but that comes "for free" when you mmap() because you specify the address. This would only be a problem with HURD-like systems, because there is no overhead if the filesystem driver runs in kernel space along with whatever other subsystems it needs to use.

I know everyone hates backseat designers, but I'd like to know if the following approach has been considered:

Make two new system calls, say "readaddr" and "writeaddr". These work like read and write, except that you also specify an offset (perhaps with a "whence" field like lseek). This saves you the overhead of calling seek all the time by combining the operations into one system call. This might be useful for other things as well, but I would imagine a filesystem driver is one speed-critical piece of code that does a lot of jumping around. Actually, I just remembered that there already are calls for this: pread/pwrite.

Another possible approach: using mmap is nice, but mapping in an entire partition is fubar. Why not map in specific parts of the partition as they become needed? Eg, keep superblock mapped right away from startup, and map in other parts as they are needed. Seems a bit complex, but could be done more easily with another layer of abstraction (some library which keeps a hash or something of mmap()ed bits and provides a nice interface for filesystem drivers). I'm guessing mmap was used as this transfers certain operations (eg, cache management) "deeper" into the "kernel" and avoids code duplication.

But anyway, mmaping an entire partition is really nuts. They're not getting any sympathy from me.

Re:Delayed???

[gmack]

I actually watched Stallman speak in Montreal recently. One interesting tidbit was that he still seems dumbfounded about the fact that the Linux kernel beat them into production even though one of the advantages of microkernel is supposed to be ease of design and the fact that mach had half of the work done already.

So, Linus was rfight?

[Royster]

From Open Sources: Voices from the Open Source Revolution

So at the time I started work on Linux in 1991, people assumed portability would come from a microkernel approach. You see, this was sort of the research darling at the time for computer scientists. However, I am a pragmatic person, and at the time I felt that microkernels (a) were experimental, (b) were obviously more complex than monolithic Kernels, and (c) executed notably slower than monolithic kernels. Speed matters a lot in a real-world operating system, and so a lot of the research dollars at the time were spent on examining optimization for microkernels to make it so they could run as fast as a normal kernel. The funny thing is if you actually read those papers, you find that, while the researchers were applying their optimizational tricks on a microkernel, in fact those same tricks could just as easily be applied to traditional kernels to accelerate their execution.

Re:GNU/Hurd

[amccall]

The Intel guys got Linux compiling on their compiler several months ago. Look it up. The patch was small, and it should already be in development kernels.

So, replacement for gcc, replacement for libc(bsd/other libc's mentioned), replacement for all other standard unix utilities.

As a side note several other OS projects use the GNU compiler to create their binaries. Should the be called GNU/Projects as well, even though they use few if any other GNU components? And I thought GNU and the FSF was about freedom....

Re:depend on what you mean by "right"

[Ian Bicking]

I have no idea whether the GNU/Hurd does or does not address them, and even if it does, it is 15 year old technology.

The Hurd isn't really a good microkernel -- it's not really a microkernel at all, but a bunch of services built ontop of a microkernel (Mach). Of course, the microkernel is essential to the actual operation, and the services have been written with a specific micokernel in mind... but it's not unreasonable to consider the Hurd running on a different (better, more advanced, faster) microkernel. People in the Hurd community have talked about just this, though of course no one has actually done the hard work of converting it.

But sadly, my impression of what the Hurd has shown, is that just because something is userspace doesn't mean its easy to debug. It seems like code accessibility -- even for original developers -- has not been very good. I think it's in the same way that threaded programming is much harder to debug... a complex set of interworking services is even worse.

And while microkernels allow a certain level of modularity, it really should be possible to achieve a great deal of modularity in a monolithic kernel as well -- just not in as safe a manner. I don't know that safety is the difficult part of Linux development. Well... I'm not entirely clear on what is the difficult part, I've never tried to program on the kernel. Probably an issue of factoring -- when refactoring needs to occur across module boundries (for whatever reason) it requires different developers to communicate and agree on things (which is where the overload is occuring). But that same problem will exist in a microkernel -- only the refactoring will be occuring between processes. That's not a big difference.

Maybe with enough thoughtfulness you can refactor everything in the Right Way, so that interfaces are entirely stable and development can occur without as much interdependence. That's not impossible -- there's a lot of experience from Linux and elsewhere to learn from. But I don't think that is related to monolithic or microkernel design.

RMS

[thoolihan]

I'm sure I will get flamed on /. for this one, but since 98% of the comments are along the lines of "down with RMS", I have to say this.

At some point you have to decide if you are going to go along with the pithy flames or do real research. It's not popular, but it reveals the truth. If not, go to the next comment, this isn't for you.

From a proctical standpoint, I understand the "Linux" side of the argument. However, people make that argument with statemnt like... "Don't do drugs, you'll end up like the Hurd peopl" - LT. RMS makes his argument respectfully on the GNU website and encourages people to use GNU/Linux. On the GNU site, he says the easiest and best way to start using free software is to go get a GNU/Linux distro. Personally, I respect people who make their arguments with facts instead of one-liners. If you buy things because they sound like a good quick answer, then you start going for things like "trusted computing".

Finally, since this is a discussion of the HURD kernel: I think people should find this interesting. The GNU tools we are already familiar with are going to get a microkernel. Merit arguments aside, there are a lot of people who choose/like microkernels (apple, *BSD). Also, it's a kernel project that offers a ton of work to be done. After all, 1GB partitions is a sign that there is a long way to go. Entry level kernel hacking on a system that has a LONG way to go is easier than "even though you've never kernel hacked, figure out how to save a few cycles with this kernel module that has been working for five years". Also, keep in mind, the HURD has one major advantage over the Linux kernel. There is not a one man bottle neck.

Personally, I like the linux kernel and use several Gentoo systems, and some OpenBSD. But I always welcome another choice in software and look forward to seeing the HURD in a more usable state.


There is a fine line between picking your battles and cowardice