> 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)
-
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