[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ANNOUNCE] Introducing Codezero

From: olafBuddenhagen
Subject: Re: [ANNOUNCE] Introducing Codezero
Date: Wed, 8 Jul 2009 02:35:00 +0200
User-agent: Mutt/1.5.19 (2009-01-05)


On Thu, Jul 02, 2009 at 09:20:31PM +0300, Bahadir Balban wrote:
> Bas Wijnen wrote:

> I have taken a closer look at the existing Hurd implementation. It
> looks very much like what I had in mind when meaning "microkernel
> based OS using plan 9 design principles".

Not really. There *are* some similarities regarding the file system
handling -- but there are also very fundamental differences between Plan
9 and the Hurd, thich go far beyond monolithic vs. microkernel design:

- The Hurd is UNIX (POSIX) compatible

- While (almost) all services are attached to the file system tree, not
  all services actually export a file system interface!

  Personally, I advocate using FS-based interfaces as much as possible.
  Yet, there are some cases where they get very arward and/or
  inefficient, and domain-specific interfaces simply make a lot more

  Also, some Hurd services are indeed used to implement the file systems
  in the first place -- they work *below* the FS level, and obviously
  can't use an FS interface!

- File systems are completely decentralized -- clients always talk to
  the FS servers directly, without any central VFS layer. (I don't think
  that's the case in Plan 9?)

  This offers much more flexibility -- the way the FS interfaces
  themselfs work can be modified. Many things can be implemented as
  normal translators, that would require special VFS support on other
  systems. (Extended attributes, VFS-based union mounts, local
  namespaces, firmlink, magic file name suffixes etc.)

- The system design allows users and applications to change almost all
  aspects of the system functionality in the local environment easily
  and without affecting other parts of the system.

  (This is possible with Plan 9 to some extent; but the Hurd allows it
  at a much lower level -- including stuff like the filesystem
  interfaces, access control mechanisms, program execution and process
  management, and so on.)

I hope I didn't forget any major differences...

> Essentially a Hurd translator setup with settrans is what a file-based
> server does when mounted in Plan 9.

Yes, aside from the differences listed above...

>> I don't have enough idea about the code to know how good that would
>> work.  Does your kernel use dynamic memory itself, by the way?  In
>> other words, can the kernel get out-of-memory errors?
> Currently, we do have this. There is a very rigorous memory allocation
> policy though. Page tables, thread control blocks and space structures
> are allocated which are only related to thread and address space
> creation. These can be easily controlled by introducing limits or
> capabilities on thread and address space creation.

We don't really want this kind of fixed limits in a general-purpose
system... This is actually one of the major concerns behind all the
design work regarding new Hurd implementations.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]