Hi, On Mon, Jul 13, 2009 at 11:36:25AM +0300, Bahadir Balban wrote: > [email protected] 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-
