From Nicolas.Williams at sun.com  Mon Jun 22 20:23:16 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 22 Jun 2009 22:23:16 -0500
Subject: [cpg-discuss] CPGs and "legacy" process groups
Message-ID: <20090623032315.GN1308@Sun.COM>

One of the ARC inception comments was "why not use id_t", and another
was "see if you can make CPGs represent/interface/deal with System V
process groups and session IDs" (paraphrased).  These two are related,
so I'll address them here.

With respect to the first issue ("why not use id_t") I've concluded that
using id_t is, indeed, quite helpful.  Specifically:

a) my concern about unique ID management is addressed by the fact that
Solaris has a reusable id_t allocator (see id_alloc());

b) any library function or system call that takes an id_t/idtype_t pair
of input arguments can refer to CPGs without further ado if we switch to
using id_t.

Therefore I will update the docs and prototype to use id_t.

With respect to the second issue ("what about pgrps and sids") the
situation is more complicated.  Having a single CPG ID namespace means
that the cpg_*_byid() CPG system calls don't need an idtype_t input
argument.  Representing "legacy" process groups via the CPG API
necessarily implies having multiple CPG ID namespaces, which means
adding an idtype_t argument to all those functions.

That's manageable for all but cpg_change_byid() (it does somewhat
complicate the use of the other cpg_*_byid() functions).  Enough so that
I'd rather remove the cpg_change_byid() system call, which in turn makes
it much harder for one to join a process to a CPG where one only knows
the type and ID of it but not the PID of any member (i.e., impossible
when the only remaining references to a CPG are from open file
references).  Now, since joining an existing CPG by ID is probably not
going to be a common operation, and since I see no use for joining a CPG
with no remaining members, I think this is probably fine.

I want to sleep on this second issue some more before deciding it, and
would welcome advice and comments.

Also, with regards to actually replacing parts of the implementation of
any of the "legacy" process groups with CPGs...  I'm not sure that it's
worthwhile, and I'm certain that it's not worthwhile as part of the
initial push.  The only legacy process groups which I think could be
considered for such implementation replacement (and then only some parts
of them) are:

 - System V process groups
 - SVR4/BSD sessions
 - project (not really a process group, but treated as such via idtype_t)
 - tasks
 - process contracts
 - audit context (and audit session IDs)

But note that the semantics of these are, mostly, significantly
different from CPG semantics, specifically:

 - pgrps and sessions: ID namespace shared with process ID namespace;
   change of pgrp/sid allowed only in some cases (when the process is
   not already a pgrp or sid leader), and with side effects
   (dropping/changing ctty)

 - projects: not really a group -- can't create new ones, can only
   change project ID, and only by joining a new task

 - tasks come pretty close to CPG semantics

 - process contracts can only be created at fork time, can't be parted,
   can't be joined

 - audit context requires privilege to get/set but otherwise is very
   similar to CPG semantics

Of these, then, the most awkward to represent as CPGs are pgrps,
sessions and projects.  But there are some advantages of being able to
do so, if we were to succeed, such as being able to use
cpg_getuserdata() to find the ctty name for a process group or session.
The biggest problem with pgrps and sessions is the fact that the ID
namespace must be different from that of all other CPG types.

I'm quite tempted to reject any idea of representing pgrps and sessions
as CPGs.

Comments?  Advice?

Nico
--