|
Description
|
[dep, 25Feb2008]
With the integration of
PSARC 2008/046 Process Contract Decorations
5079353 RFE: contract 'decoration' with service FMRI
the kernel tracks SMF FMRIs and additional data for each process
contract on the system. While it is possible to manually construct
an expression that navigates the various kernel data structures to
access this information, it would be much better if we could access
it directly using a simple, stable interface.
At the very least, an equivalent to "execname" that represents the
SMF FMRI of the current running process would be extremely useful.
The ability to easily obtain the creator of the contract and the
method name (e.g "svc.startd" and "start", respectively) would also
be handy.
[ahl 2.25.2008]
It seems like this is a datum which belongs in the psinfo_t structure in which case you can easily access it from DTrace by looking at curpsinfo->pr_fmri (or whatever). Would that suffice?
[dep, 25Feb2008]
These are attributes of a process contract, not of a process. Adding
them to psinfo_t is technically possible, but would be redundant and
would be setting an unusual precedent (i.e. what makes this different
from other data associated with objects associated with processes
that isn't found in psinfo_t?).
[ahl 2.27.2008]
In what was would this be redundant? What stable structure in /proc is used to expose the SMF FMRI? Are you asking why not make fmri a global variable ala pid or execname? Because fmri will be less used and because it creates an incompatible change (e.g. if a script already uses fmri as an identifier).
[dep, 28Feb2008]
There are two issues here that shouldn't be confused:
1) Whether this information belongs in psinfo_t
As I explained earlier, the FMRI is a property of the process
contract, not a property of the process. Just like we wouldn't
put project, task, pool, or zone attributes in psinfo_t, we
shouldn't put contract attributes in psinfo_t. Doing so would
simply be turning psinfo_t into a dumping ground for the
convenience of dtrace.
psinfo_t does include the contract id a process is a member of,
which can in turn be used to look up contract details in
/system/contract (...or in the kernel, though that would be a
roundabout way to get at a structure pointed to by proc_t).
2) How this information should be exposed in DTrace
I actually don't care how it is done. I suggested a global only
because that's what Bryan suggested in his original request for
this functionality.
My recommendation would be at least to have some way to map from
process to process contract, and to have a translator from process
contract to a stable structure (or structures) that contains the
useful process contract attributes (contract id, service FMRI,
creator, etc.).
|