Re: [ANNOUNCE] Introducing Codezero

[olafBuddenhagen]

Hi,

On Mon, Jul 13, 2009 at 11:36:25AM +0300, Bahadir Balban wrote:
> address@hidden wrote:

> Obviously in a microkernel system, to provide the file-io interface
> certain core servers are not going to have this interface. I always
> meant file-io is only to be provided by services that are attached to
> the process namespace. But inside the namespace, file-io should be
> used  as much as possible, instead of object-specific methods on every
> and  each path component.

I actually agree on this approach: use filesystem-based interfaces by
default, and use custom RPCs where this is more appropriate for some
reason.

Not all Hurd developers agree on this though... The current Hurd is
somewhat in between I'd say.

> Could you please describe the sequence of events on how you could
> implement a POSIX system call using a decentralized model?

This is actually one part of the Hurd that is (somewhat) documented...

Basically, the idea is that every lookup starts with the server
responsible for the base node. (Root directory for absolute lookups, or
working directory for relative ones.) The client has a port for this
node, and sends the lookup request there. The server then looks up all
path components it is responsible for itself. When it encounters a mount
point, it tells the client which server is responsible for that mount
point, and the client contacts this server directly, to continue the
lookup with the remaining path components.

> By limits I didn't mean fixed limits. I generally try not to design
> things using fixed limits. But you certainly should have limits to
> resources. These can dynamically change.
>
> In Linux, there are limits to how much while(1) fork(); you can do,
> which is useful for obvious reasons. Those limits can be changed by
> system calls.

Note that on a multiserver system, this is much harder to implement, as
it's not very helpful to limit the server processes -- you have to keep
track of which clients are actually responsible for resource use.

Anyways, this is indeed what I mean by "fixed" limits... It is a rather
ugly workaround for the lack of proper dynamic resource management. The
amount of memory a proccess is allowed to use for example should *not*
be determined up front by a static limit, but rather be decided
dynamically on resource availability and priority of the process.

This is a non-trivial task. The Viengoos papers and prototype
implementation propose a framework for doing it right.

I'm not claiming that the current Hurd does this properly -- but it has
been the major motivation for new Hurd designs. If we create a new Hurd
design, let's do it properly; or else we can stick with the existing one
just as well...

> It seems this can be done using capabilities, and I  don't think L4 is
> such a bad candidate for implementing them.

Nobody said that L4 is a bad candidate for implementing capabilities...
In fact, all new work done on L4 over the past couple of years has been
about this.

This was precisely what motivated my original question: I was a bit
surprised that you are basing your work on the Pistachio design, rather
than some of the newer variants...

-antrik-