The debian project has some interesting developments related to its GNU/Hurd port, including a solution to the annoying limitation mentioned above.
The debian project has some interesting developments related to its GNU/Hurd port, including a solution to the annoying limitation mentioned above.
Just now? Wow. I knew HURD was progressing slowly, but I didn’t know it hadn’t even made it to this century yet.
That’s so pathetic. The advantages of Linux over HURD are a thing of the past.
😛
This is an honest question? GNU/HURD (note the “GNU,” God help us!) was started to be a completely free implementation of a UNIX-like operating system under a license which RMS saw fit. Linux is that system. Is this about RMS’s ego, or is it really about free software. Or does he have a fetish for microkernels? Though I believe it is a boon to the free software movement to have some purists still on board, a necessary characteristic of a leader of any group is to be able to pursue the goal above personal interests. OR better yet, that the goals of the group and the goals of the individual might become one. This is honestly something that has bothered me about RMS.
It’s clear that GNU/HURD is behind the times on features, but if the developers want to work on it, who am I to tell them not to? I don’t understand why people get indignant about the state of an OS they don’t use. To each his own. Let people do what they want.
Good progress, Hurd devs. Cheers. I think I should try Debian/Hurd again soon.
Hurd was supposedly started in 1990, a little bit before Linux during a time when microkernels were all the rage. Of course you have to factor in RMS’s megalomania into the equation and his bitterness that everybody isn’t running around calling Linux, GNU/Linux.
Apparently RMS “fired” a Hurd developer a while back even though RMS doesn’t contribute directly to Hurd (or so the story goes).
How small is this ‘microkernel’ anyway? BSD’s kernel must be monolithic because Generic kernel takes about 5 Mb. This size of a kernel fits only in a RAM, but could there be some day when kernel fits on a L1 or L2 cache?
now that would be fast!
While Linux is currently more featured than Hurd, that doesn’t mean that Linux will always be. Software development has both legacy and modern solutions. The legacy solutions have a lot of features and have been around for a while, but things start getting to the point that new features start getting hacked on and such. Modern solutions don’t have all the features, they aren’t complete, etc, but they have the advantage in organization and ease of coding. That’s the way it will always be. No one can ever interpret a solution that will alter well to everything in the future.
As for microkernels, they are a much better design. Linus Torvalds says that microkernels are better even though the one he designed is monolithic.
GNU/HURD (note the “GNU,” God help us!) was started to be a completely free implementation of a UNIX-like operating system under a license which RMS saw fit
Hurd is Hurd .. not GNU/HURD … GNU was the OS and it is complete thanks to the Linux kernel. Yes, it is GNU and always will be (except for the idiots who can’t differentiate between a kernel and an OS). I personally don’t call it “GNU/Linux” , but I still have to say that without RMS we would have MicrosoftBSD and AppleBSD (oh, wait) and god knows how many thousand proprietary forks of it. Eventhough there are around 20-odd trees in Linux kernel, it still hasn’t forked in a conventional sense.
Btw, eventhough Linus Torvalds himself admits that Microkernels are better – Linux has had an eclipsing effect on Hurd by pulling all the developers (potential developers) out of it.
I still think Hurd has the potential – it just doesn’t have the developers.
Or we get 8mb L2 caches. How big is Itanium’s L2 cache? I think it may even be 8mb.
I think HURD is an uber experimental branch of the Linux kernel. They are both licensed with the GPL, so I see no reason why code can’t be taken from one and merged into the other. The HURD design may one day prove useful in certain situations that require more modularity than the Linux kernel is prepared to offer, but it will be a few years.
One potential puzzle I could see HURD working on is how to share processes between multiple CPUs instead of just splitting up the execution as in most SMP configurations. Or sharing processes, hardware and software resources over the net in a more modular/granular way. That sort of thing.
Wouldn’t this problem be easily fixed in the 64bit port? With mapping working in 64 bit memory space?
Re Lars…
How small is this ‘microkernel’ anyway? BSD’s kernel must be monolithic because Generic kernel takes about 5 Mb. This size of a kernel fits only in a RAM, but could there be some day when kernel fits on a L1 or L2 cache?
On my notbook…..
1.9M /vmlinuz-2.6.9 # Linux
776K gnumach.gz # GNU Mach 1.3
188K ia32-kernel # l4-pistaschio
Of course, my notbook only has 64K of L2.
Re hmmmm:
I think HURD is an uber experimental branch of the Linux kernel.
No, it’s not. GNU Mach and the Hurd servers are completely different than the Linux kernel in their design and operation.
I see no reason why code can’t be taken from one and merged into the other.
They do. Most of the device drivers in GNU Mach came from Linux (2.0, mostly), and the pfinet server is a userland implementation of the Linux TCP/IP stack.
One potential puzzle I could see HURD working on is how to share processes between multiple CPUs instead of just splitting up the execution as in most SMP configurations. Or sharing processes, hardware and software resources over the net in a more modular/granular way. That sort of thing.
It’d work very similarly to OSX, which also is mach at the core. Supposedly, Mach IPC does work over the network, although I’d imagine it’d be painfully slow for most things. As network hardware gets faster…..never know, though?
Re zele:
Wouldn’t this problem be easily fixed in the 64bit port? With mapping working in 64 bit memory space?
Yes. 🙂 But right now, mach-based Hurd only runs on IA-32, and that’s still the vast majority of systems out there. I communicated a bit with a guy who was working on getting it to run on 32-bit PPC, but that platform would have the same problem. Is there a 64-bit version of mach out there where people might be able to experiment a bit? I don’t know……OSF on Alpha or Sparc, maybe?
I like the idea of hurd.
I’m sure there was once a time when other kernels had far more features then linux.
As hurd matures, I hope to end up using it. I have no dislike of linux, but it is only a kernel and having the choice between kernels when installing, say debian, would be a nice thing indeed. (On that topic, I know of the freebsd|netbsd port, looks cool).
One day, when a big kernel feature will have to be implemented in the Linux kernel, and that feature will be very hard to integrate into the Linux kernel, then, the Hurd will prove to be a faster development solution for this feature.
But what feature is it ? Maybe multi-computer OS (like Plan 9 and such…), I don’t know…
But… I thought they just needed to incorporate GNU GPL code into it? Why don’t they use pure GPL code from some other GPL’d filesystems?
you don`t have any way to put things int the L1 L2 or even L3 chace
I thought they just needed to incorporate GNU GPL code into it? Why don’t they use pure GPL code from some other GPL’d filesystems?
The GNU Hurd’s file systems are implemented in user space and run as translators invoked by access to the file system node they are attached to. They also build on top of the pager and diskfs libraries also provided by the Hurd. So their design is quite different from e.g. Linux’ fs kernel modules.
There are many (good) drivers missing in Linux, because the specs are proprietary and the manufactorers won’t develop drivers for Linux. And it will take a long time until you have nearly as less problems with drivers as under Windows.
I think when Hurd is comming out, it will take many many years until you have enough drivers to be a real alternative – at least for desktop systems. Or is there some kind of a Linux-compatibility mode in Hurd?
Wasn’t HURD going to dump Mach and switch to an L4 microkernel implimentation? Or at least investigate the possibility? How did it turn out?
is there some kind of a Linux-compatibility mode in Hurd?
Actually, low-level hardware drivers do not reside in the Hurd, but the GNU Mach microkernel it sits atop of. GNU Mach uses Linux drivers, albeit only 2.0 or 2.2 ones.
Wht matters if you run the “Microkernel” in the L2? At the end, you’ve lot of servers implementing drivers and all that.
That don’t fits in the L2, and you’re going to run it so frecuently as the microkernel
“One day, when a big kernel feature will have to be implemented in the Linux kernel, and that feature will be very hard to integrate into the Linux kernel, then, the Hurd will prove to be a faster development solution for this feature.”
Modularity, extensibility, etc is NOT a “property” of microkernels. It’s a property of the code. It can be achieved in microkernels and monolithic kernels. In fact you can achieve the contrary in a microkernel, Hurd could be very well a unmainteinable mess – just make horrid APIs.
you don`t have any way to put things int the L1 L2 or even L3 chace
Isn’t the idea of cache that it has last used codes near CPU memory if you use it freguent enough and isnt kernel runnin in a loop over and over again. So it would be reasonable that it has at least some part of kernel in L1 or L2 memory, or at least some algorithms. I’m not a developer of anykind so this is just “i think …”-kind of information.
Like the idea of what i’v been planning is to get SCSI HD size of 10Gb and make it as swap so that i could run windows in VMWARE as fast as native IDE. Would this make any sense if i keep my machine open all day long?
The cache stores recently/most frequently accessed data from RAM. However, it gets flushed on a context switch, so that programs can reside in the cache for faster execution. Therefore, no part of the kernel will reside in the cache all of the time.
It’s funny how in the famous AST vs. Linus flamewar, one of the arguments posed by AST is that Linus shouldn’t have bothered writing his own kernel, since GNU would be out very soon, and would own the world. Linus himself believed that, but he wanted a free kernel right there and then, so he thought the best solution was to write one himself.
Funny how differently things turned out to be. Linux ended up fulfilling the political/social function that Hurd was supposed to take, and won out on being available right there and then.
Question for Anonymous (IP: —.dmz.cme.nist.gov) or anyone who can answer.
Would it be possible for a chip maker to build a special L2 cache just for the Kernel? I am thinking that someone like IBM could build a special Power5 chip a special kernel cache and sell a very high performance system that runs a modified version of Linux or AIX that gets its kernel loaded into the special kernel cache. Seems that it could provide a considerable performance boost.
How small is this ‘microkernel’ anyway? BSD’s kernel must be monolithic because Generic kernel takes about 5 Mb. This size of a kernel fits only in a RAM, but could there be some day when kernel fits on a L1 or L2 cache?
now that would be fast!
This is especially not true with a microkernel. Most things are done in userspace with a microkernel therefor the majority of the work would be done outside of the kernel and only message-passing would occur in the cache, at the kernel level.
Linus Torvalds himself admits that Microkernels are better
Not true. Read “Just for Fun”. Linus thinks they are overhyped.
It’d work very similarly to OSX, which also is mach at the core.
OSX isn’t really similar though, even though they both use mach. First of all, from what I hear the HURD is going to be switching to a newer and better microkernel like L4. Second OSX is more of a hybrid kernel, than a true microkernel, for the sake of speed.
Would it be possible for a chip maker to build a special L2 cache just for the Kernel?
If the memory where the kernel is stored is accessed more often – it will be put in the cache anyway.
Modularity, extensibility, etc is NOT a “property” of microkernels. It’s a property of the code. It can be achieved in microkernels and monolithic kernels. In fact you can achieve the contrary in a microkernel, Hurd could be very well a unmainteinable mess – just make horrid APIs.
The GNU Hurd is not a microkernel, it merely uses one (GNU Mach at the moment). The Hurd is a set of user-space servers which sit upon the microkernel and (as one feature) together with glibc presents a POSIX personality to userland (all the usual Unix system calls are implemented in glibc, for example).
Furthermore, the architecture and APIs of the Hurd are pretty clean and developer-friendly, in the opinion on the people hacking on it. They have been developped by the same GNU guys who brought other stuff like glibc to you.
Do modern caches still have to be flushed on every context switch? This takes much of their use away, especially in messaging environments.
I thought I read at some time that modern caches mirror not ONE process’s logical memory but rather all physical memory so that you can context-switch all you want — the cache just does a nice LRU on the whole system’s memory accesses.
Mach vs L4:
does anyone know the “official” status?
Markus, do you have L4 running on your Linux system? What can it do already?
The last question should go to hurdboy, not Markus, sorry.
I basically followed the instructions here: http://hurd.gnufans.org/bin/view/Hurd/HurdOnL4
It boots very quickly, and throws you into a debugger. That’s about it for the moment. From what I’ve read on the lists, they’ve got a pretty good idea about what servers they’ll need for basic operation, but most of those haven’t been written yet. Again, the philosophy is design, then code, not the other way ’round. 🙂
Yes I recall re-reading that debate in the last month or so, I found it quite amusing. Interestingly enough AST also stated that we would be running on some kind of risc architecture – ppc i think and criticised Linus for making a 386 orientated kernel. This becomes incredibly ironic now that Linus uses a ppc to work on. And even more amusing when you consider that modern x86 chips are really risc emulating cisc.
That may be the case. However, you’ll still be throwing processes into the cache, so they’ll still be using up the same space as parts of the kernel. So, yes, if that were the case, you could fit the entire kernel into the cache, but much of it will be removed when other processes get moved in.
To Andrewg: Why L2 cache? If a chip maker were to do that at all, they’d most likely have a block of RAM onboard dedicated to the kernel. However, with current designs, that may pose a problem with the external RAM, as either of the 2 blocks would be inaccessible to the CPU, depending on address mode, or just overlay, as would be more likely the case (internal RAM masks the external RAM for those memory addresses).
“Furthermore, the architecture and APIs of the Hurd are pretty clean and developer-friendly, in the opinion on the people hacking on it. They have been developped by the same GNU guys who brought other stuff like glibc to you.”
I really hope it isn’t, I’ve only heard horror stories about GNU libc’s internals.
The cache stores recently/most frequently accessed data from RAM. However, it gets flushed on a context switch, so that programs can reside in the cache for faster execution. Therefore, no part of the kernel will reside in the cache all of the time.
No, this is wrong. You’re thinking about the TLB which gets invalidated on every context switch. That is a cache for the page tables for the running process, not a general cache like the L1 and L2 caches. The Intel architecture provides no mechanism for software control of the program/data cache; the CPUs participate in a SMP and DMA coherency protocol in hardware.
I really hope it isn’t, I’ve only heard horror stories about GNU libc’s internals.
So what? Why don’t you look for yourself instead of listening to other people’s horror stories? glibc’s reputation is for bloat, not bad code.
One of the drawbacks with the microkernel architecture is that system calls require a context switch, which can take a fair amount of time.
This is because things like filesystem access require modules that reside in their own user space processes (and hence require their own addressing space, memory protection and other overheads). This is arguably a Good Thing.
Modern processors have for years been optimised for monolithic kernels. If there was special hardware, designed specifically for the microkernel architecture, things might be more equal.
IMHO, the best things about microkernels are:
– clean abstraction and protection (just because my mouse driver contains a bug doesn’t mean that my system should panic!)
– potential for massive parallelisation – as each component runs as a separate user process, desktop systems with 10s of low cost processors would allow true parallelisation of the operating system
– potential for distribution – as modules communicate using IPC, there is no necessity for them to reside on the same system – communicating with a local filesystem would be the same as communicating with a filesystem across a network
Modularity, extensibility, etc is NOT a “property” of microkernels. It’s a property of the code. It can be achieved in microkernels and monolithic kernels. In fact you can achieve the contrary in a microkernel, Hurd could be very well a unmainteinable mess – just make horrid APIs.
I must say I agree with this. Don’t confuse source-level and code-level modularity!
Microkernels sound good, there are some lovely ones out there, but I’m not sure what to think anymore. I do know for sure that I don’t like big kernel images with all the drivers, filesystems and such blobbed together. Actually I think that Windows NT’s model is a better idea, but it still exposes the problem of dodgy drivers crashing the system (Is this an unjustified/imaginary perception?)
I have this idea about loading the kernel and driver modules in to one virtual address space, each module/area aligned to 4MB, and flipping the write bit at the top level page table for each appropriate “mini address space” when you wanted to make sure that bad drivers don’t corrupt stuff that they shouldn’t access. I have no idea if that would perform efficiently or not, but I thought it’s a crazy enough idea that it might work.
“So what? Why don’t you look for yourself instead of listening to other people’s horror stories? glibc’s reputation is for bloat, not bad code.”
Because I trust the people who said it (some kernel developers) more than myself when it comes to “code”