That is pretty much what is being proposed for process aggregates. In addition
to the ID's we also want to allow additional information be contained inside the
process aggregate container. That data could be handled by kernel modules that
implement specific container types.
This would allow for more flexibility when implementing such things as limits
based upon the container.
Ton Hospel wrote:
>
> > On Fri, Jun 16, 2000 at 03:21:19PM -0500, Sam Watters wrote:
> ...Stuff about accounting "jobs"...
>
> Ever so often you see yet another proposal for someone adding yet
> another process id. Whether you agree with any specific one or not,
> it seems there will not soon be an end to this.
>
> How about formalizing adding "id's that default to being constant
> over fork" as a supported (possibly even dynamic) kernel feature.
> you could e.g attach an id vector to each process which would normally
> just get it's pointer copied on fork, and COW (or hash lookup) on changes.
> in there you could by default put uid, gid, fsuid, pgrp etc., and have an
> interface where you can allocate/deallocate a new slot in the vector for
> any extra id's you would need (at least at config/compile time and maybe
> even at run time).
>
> You loose in needing extra dereferences in looking up an id, but
> might gain it back with a shorter task struct and the fact that many
> processes will share this vector, so hopefully it can be cache-hot
> (or maybe leave the REALLY hot ones in the task struct and/or have a
> "current" for this vector)
>
-- ---------------------------------------- Sam Watters SGI watters@sgi.com (651) 683-5647 ----------------------------------------- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:21 EST