At Fri, 21 Oct 2005 08:03:47 -0400, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > > On Thu, 2005-10-20 at 16:17 +0200, Marcus Brinkmann wrote: > > At Thu, 20 Oct 2005 02:31:20 +0200, > > <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > > For example, process instantiaton (spawn or fork) requires many > > > > capability copies even in our current plans. Creating new processes > > > > is an important operation in the EROS operating system to enforce > > > > confinement policies. > > In KeyKOS, processes had a grand total of 16 capability registers, and > no capability address space. In EROS, we went to 32, but we didn't need > it often. Also, in practice, we will find that most of the capabilities > transferred are the capabilities associated with the "standard > environment" -- things like stdin/stdout and so forth. These can be > bundled into a single bundle that is transferred as a unit.
This leads me to a different question. Say a process has 1000 open files. For many applications, this seems like an unreasonable number, but if I search hard enough, I am sure I will find some applications which do this. Or let's say it's a server and 100 sockets. Anyway, it boils down to 1000 capabilities being in active use. Where do you store them? It seems that you have to create a node hierarchy to store so many capabilities. And every time you use one, you have to copy it into one of the registers. This seems to require a system call (looking at the implementation). Isn't that a bit of a downer? Moreover, this scheme can't support more than 32 threads invoking CALL at the same time. I understand that EROS applications are single-threaded. Are there any plans to rectify some of this in Coyotos? Ie, by using a capability address space, for example? Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
