Re: Two fixes for 2.4.19-pre5-ac3

[Jan Harkes]

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