On Sun, Apr 07, 2002 at 09:01:47PM +0100, Alan Cox wrote:
> > Either add getpag/newpag natively (good for yearly flamefests in
> > linux-kernel), or the more generic task-ornaments so I can make a
> > trivial module that adds /dev/pag, semantics could be as simple as
> > reading returns the current pag, and writing adds a new pag as a
> > task-ornament.
>
> Oh look, more dirt is falling out now we shook the tree a little. I have
> zero problems with the PAG. We also need an luid and some other related things
> in the future to do strict resource management on big systems (think of it
> in this case as an accounting charge code)
Correct, there is already a whole bunch of ID's and associated with a
task structure, and each has their own little niche.
process id
parent process id
process group id
session id
thread group id
session group leader
user id (4 flavours)
group id (also 4 flavours)
groups (array)
a 'user' struct
various 'thread group tracking' identifiers
journalling filesystem info (whose? ext3? reiserfs? XFS? what if I
use multiple journalling filesystems?)
(and there is probably more)
And there is a continuing request to add even more things like,
process authentication group id
login user id
etc. etc.
And all of these have different requirements and lifetimes. I believe
task-ornaments are a pretty clean way of allowing most this kind of data
to be added dynamically if it is needed or used. If the core kernel
doesn't need some 'task identifying field', it probably should not have
ended up in the task struct. But until recently there simply was no
other solution if one needed process related information that is shared
or inherited across a fork.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 07 2002 - 22:00:20 EST