[comparing essentially with linux 2.6 here because it's state-of-the-art and the one I know best]
On Thu, Jan 22, 2004 at 01:10:43AM +0100, Marcus Brinkmann wrote: > You have to put it into the perspective of OS design history. The success > of Mach is to show that splitting up a kernel in a generic core part and a > specific server component (or multiple) is possible. It's only a first > step in a new branch of the still short history of OS design. Sure. It was interesting at the time, no doubt about it. But it stopped evolving 10 years ago, and OS engineering didn't. And, as you very well know, having in 2004 a multiserver OS based on a 1990 mach version, and 1990 mach concepts, just doesn't work out. > Also, you will have a hard time to substantiate your criticism. I don't say > that your criticism is wrong (in fact, I agree), but "sucks" is an > evaluation that tells us more about you than about Mach :) "sucks" was just a shortcut for "considered obsolete by current standards when compared to the semantics and performance provided by modern systems". > If you want to > analyze for example the IPC performance, you will find out that a lot of > research was necessary to find out exactly _why_ it sucked and what can be > done to fix it (and it _can_ be fixed). Is the why anything else than the cost of the minimum of two VM switches per exchange with a server plus the small amount of inter-VM copying needed? Which is a large, incompressible cost in the ports model. The marshalling/unmarshalling cost on top is just gravy. What were they smoking? Fixing it must be fun though, I'll have to look up the proposed solutions. Comparing with the linux syscall speeds will be _tough_. > I don't say that the burden is on > you to do this. You can very well lean back and watch if it happens, and > until then you can feel comfortable knowing about the superiority of > existing traditional solutions. The solutions I consider superior are hardly considered traditional. The trend for thread/process unification is reasonably recent, and the recognition of the value of a clone-like syscall where you create a new scheduler object and cherry-pick what you want to share isn't very old either. Or the futex approach to locking. Or the O(1) scheduling. Or the full memory cache unification. They appeared a while ago in various oses (BSD, plan9...), but they're understood as the Right Way[tm] to do things for max 5 years. You'll notice btw that what I cite is not incompatible with a microkernel approach (well, the cache unification may be hard). It's Mach itself I consider badly designed by today standards, not the microkernel concept per se. > However, this is not a contest. We are not in competition with anyone in > terms of performance, security, etc. There is no price to win if we are > better in any category. What you win, or nowadays lose, is volunteer developpers. Imagine someone new who wants to play with OSes and trying to find out what Hurd should eventually have that the others don't have. The gnu.org Hurd page is pityful in that aspect, all the features it cites are covered by current monolithic kernels. The Hurd on L4 page boils down to "L4 is better than Mach" (well _duh_), and half its "Related item" links are dead. If the developper digs deeper, the only thing he'll find is the translators, which can be seen as a combination of triggers (soon coming as "mount traps" on linux, only missing the persistence at filesystem level) and userland filesystems (already existing). And that's it. Nothing else potentially interesting is ever cited. So, well, if it's only to redo what already exists and with less hardware support, he may not be very motivated... > Indeed one of the major problems with Mach is its centralistic VM system. > You should be interested to learn that in Hurd on L4, we plan to have tasks > be self-paged, and be provided with physical memory. Clever protocols will > allow untrusted tasks to share memory and even allows zero-copying from the > device driver directly into an untrusted user's buffer. Sounds cool. > Again, this is all "dream land", as you called it. But you can not even > hope to get there by "accident", or by incremental optimization of a working > traditional solution. Dream land was about userspace drivers miraculously making the system more stable. Zero-copy to/from userspace is so not dream land that it's already supported in linux. OG. _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd