Jason,
I am interested in this happening, so I thought I would at least
comment.
Some of my questions are more implementation detail specific, but I
hope they should incite some more dialog about your proposal ;)
Good stuff, questions/comments in-line
-ejo
On 7 Apr, at 2:25 PM, Jason King wrote:
Stability attributes:
The thinking is unless there's a good reason to diverge, for
consistency (and sanity of someone trying to figure out what to use),
I think keeping it analogous to the dtrace attributes makes the most
sense:
typedef uint8_t kstat_stability_t;
KSTAT_STABILITY_INTERNAL internal to kstat system
KSTAT_STABILITY_PRIVATE private to ON, the default for
all kstats
KSTAT_STABILITY_OBSOLETE scheduled for removal
KSTAT_STABILITY_EXTERNAL maintained by a 3rd party
KSTAT_STABILITY_UNSTABLE new or rapidly changing
KSTAT_STABILITY_EVOLVING less rapidly changing
KSTAT_STABILITY_STABLE mature interface
KSTAT_STABILITY_STANDARD industry standard
KSTAT_STABILITY_MAX maximum valid stability
Kernel Interfaces:
int kstat_set_stability(const char *ks_module, const char *ks_name,
kstat_stability_t stability);
Desc: set the kstat to a given stability level
Returns: 0 - success
EINVAL - stability level isn't valid
ENOENT - kstat doesn't exist
??: should this be mutable, or should it be allowed to only be set
once, and return an error from there on out?
My intuition says that it should be immutable but I can think of
(contrived) situations where the stability level might be changed
after the fact.
Looking at the interface signature, I wonder why you chose to specify
the kstat using module and name? Will the stability be added to the
kstat_t structure or will it be in an auxiliary dictionary separate
from the kernel kstat chain?
If it's not separate, it makes more sense to me to modify
kstat_create() to take a new argument. Oh great, I just realized why
that won't fly. The advertised stability of kstat_create() probably
won't allow us to modify it all willy nilly ;) Never mind.
I still have the feeling the signature should be something like:
int kstat_set_stability(kstat_t *ks,kstat_stability_t stability)
The thinking here is that authors will create kstats first and then
tweak the stability.
int kstat_get_stability(const char *ks_module, const char *ks_name,
kstat_stability_t *stability);
Returns: 0 - stability value in stability. If the stability value was
not explicitly set, *stability contains KSTAT_STABILITY_PRIVATE.
ENOENT - kstat does not exist.
User interfaces:
int kstat_get_stability(kstat_ctl_t *kc, const char *ks_module, const
char *ks_name, kstat_stability_t *stability)
Similar to kernel interface
Returns 0 on success, -1 on failure. On failure, errno is set to:
ENOENT - kstat does not exist. kstat_t
My concern here is if the stability information will reside in the
structure or in an auxiliary kernel data structure. If it is in the
kstat then it gets copied into user space when the rest of the kstat_t
is copied ( via an IOCTL ). If it is in a new data structure, we may
need a new IOCTL in the kstat device driver to accommodate.
??: How should the perl module be updated.
Sounds like we add a command line switch to kstat(3perl) to filter on
stability and teach libkstat(3perl) about the new stability user land
interfaces.
I don't think it should be especially difficult.
---
erik.oshaughne...@sun.com:Strategic Applications Engineering, Austin
Texas:512-401-1070
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
