User: Password:
|
|
Subscribe / Log in / New account

Signs of life from GNU Hurd

Signs of life from GNU Hurd

Posted Aug 2, 2011 11:51 UTC (Tue) by slashdot (guest, #22014)
In reply to: Signs of life from GNU Hurd by sthibaul
Parent article: Signs of life from GNU Hurd

It seems to me it would be MUCH simpler and better to either implement the Mach IPC interface in userspace in terms of POSIX, or as a Linux kernel module, rather than somehow attempting to run Linux drivers in Mach or some other microkernel.

Fundamentally, the Linux driver interface is enornomous, constantly changing, and partially documented, while I guess the Mach or L4 IPCs API are much smaller and well-defined.

Also, the "DDE" layer page only mentions block, network, USB and sound drivers, while of course a useful system needs at least 3D acceleration as well, plus a lot of miscellaneous stuff.

Not to mention that non-driver parts of Linux like the scheduler, MM subsystem, etc. have been extensively worked upon to be fast, reliable and scalable to SMP systems, and I don't see how anything else could possibly compare to that.

If the plan is to do MM and scheduler in userspace, then that's probably not going to be of any real use other than as a toy, and anyone using whatever new feature the Hurd provides will want to do that in conjunction with at least the Linux kernel-mode scheduler and MM so that things will work at decent performance and scale properly to SMP systems.

And of course, that way Linux users would be able to just run the Hurd easily along with existing other software.

Again, this assumes that once you get rid of everything that Linux already does (and where there's no chance at all that an userspace solution with much less developers can compete), there will be something left in the Hurd, which I'm not sure whether it's the case.

Oh, and for the record, a monolithic kernel using a managed but compiled language like Java/C# is probably much faster than a multiprocess userspace microkernel system, while having the same isolation and better security (no buffer overflows, ever!) than the latter, so the whole concept of a C-based microkernel-based system might be in fact totally obsolete.

(yeah, this is kind of a trollish comment, but I believe it reflects reality)


(Log in to post comments)

Signs of life from GNU Hurd

Posted Aug 3, 2011 7:19 UTC (Wed) by sthibaul (subscriber, #54477) [Link]

Let's answer to the troll then.

"I don't see how anything else could possibly compare to that."

"work at decent performance and scale properly to SMP systems."

Again, we don't want to replace Linux. And yes, you can have decent performance and scale properly on SMP systems without comparing to Linux, i.e. not on 1000-core machines & such. BSD kernels achieve it well for their use for instance, and there are much less companies etc. than on Linux.

"there's no chance at all that an userspace solution with much less developers can compete"

Again, we don't want to replace Linux. There's no way we can achieve the same speed etc. So what? That's not the point. The fact is that even with much less developers, we actually got to the point that the Hurd works, has 68% Debian coverage with its nice installer and the nice translator feature.

"a monolithic kernel using a managed but compiled language like Java/C# is probably much faster than a multiprocess userspace microkernel system while having the same isolation and better security (no buffer overflows, ever!)"

No buffer overflows, right. That alone does not bring full security. Yes, there are other ways to do it. Now, please bring us the code. GNU/Hurd _has_ working code _now_.


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds