Forgot to send this to the list as well. Whoops
Begin forwarded message:
From: Erik O'Shaughnessy <erik.oshaughne...@sun.com>
Date: 16 April, 2009 11:44:24 AM CDT
To: Jason King <ja...@ansipunx.net>
Subject: Re: [perf-discuss] kstat stability tags
On 16 Apr, at 12:04 AM, Jason King wrote:
On Wed, Apr 15, 2009 at 11:22 PM, Erik O'Shaughnessy
<erik.oshaughne...@sun.com> wrote:
On 7 Apr, at 2:25 PM, Jason King wrote:
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?
[deletia]
I still have the feeling the signature should be something like:
int kstat_set_stability(kstat_t *ks,kstat_stability_t stability)
Well one thing I wasn't sure about -- that means each instance could
potentially have it's own stability. I'm not a kstat expert, but for
foo:0:stat to have one stability level and foo:1:stat to have a
different stability seems odd to me. I would expect foo:*:stat to be
the same. But if my expectations are wrong, please set me
straight :)
I would expect most modules to export kstats with similar stability
guarantees, however I would hesitate to restrict providers
arbitrarily. Allowing the stability to be set per kstat rather than
per (module,name) tuple could allow providers to export kstats with
varying levels of stability commitment ( one set of exported kstats
is PRIVATE, another provides more stability guarantees ). That sort
of flexibility sounds good to me.
The general use case that I've noticed for kernel kstat providing
modules is:
1. build an array of structures for the ks_data member of kstat_t
( usually kstat_named_t's )
2. create the kstat using kstat_create(9F)
3. add the kstat to kernel chain using kstat_install(9F)
Once it's on the kernel chain it is visible to user land.
Each kstat is generally created dynamically from statically declared
elements, eg:
char *myModule= "module"
int myInstance = magic;
char *myName = "name";
char *myClass = "class";
kstat_named_t myData[moreMagic] = {};
/* initialize elements of myData here perhaps */
kstat_t *myKstat = kstat_create(myModule,myInstance,
myName,myClass,KSTAT_TYPE_NAMED,myData,flags)
#ifdef STABILITY
kstat_set_stabilility(myKstat,NEW_STABILITY)
#endif
kstat_install(myKstat);
This is a general pattern I have observed for kstat creation, some
modules undoubtedly do it differently ( but not much ).
Looking at the kstat structure, I see there are 8 bits currently
unspoken for:
uchar_t ks_resv ; /* reserved, currently just padding */
which matches the proposed kstat_stability_t definition. So I think
you are good to go in that regard as long as you can secure the OK
to repurpose those bits ( given that they are not currently in use
and this is a good use of them, I don't expect a problem ).
The thinking here is that authors will create kstats first and
then tweak
the stability.
That was my thought as well -- it would return ENOENT if you tried to
set the stability before creating the stat.
Sounds reasonable.
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.
It could be copied with the IOCTL, but it looks like the userland
struct is not opaque, so I'm concerned appending fields could break
things, though I might need to look a little closer to see if it's a
valid concern.
The ks_resv field should suite your purposes and minimize breakages
in existing tools.
Once this mechanism is in place there are more features we can add
to libkstat to provide more and missing functionality which will
make being a kstat consumer much less tedious (IMO).
As a bit of background, this is really just to clear the road to
tag a
few (~10-15) kstats with something better than 'private' so that they
can be used by another module I'm working on (snmp module w/ some
perf
counters -- if you want more details, please read the permib-dev at
opensolaris.org archives).
I'm familiar with your project and the reason for wanting to do
this. Once/if this project integrates I have a similar proposed
project that will benefit from this work as well.
I think one aspect that has gone unaddressed ( at least in the
original message ) is what it means for a kstat to be labeled with a
particular stability level. WIll the PSARC need to review changes
to kstats with a stability level greater than PRIVATE? Will the
RTI process need to be updated to ensure that kstats with upgraded
stability levels have met those commitments before they are
modified? It all boils down to how the stability levels will be
enforced I suppose, and I suspect that DTrace won't be able to guide
you in this respect since there are so many diverse kstat providers
in the kernel and DTrace is more centralized.
regards,
ejo
---
erik.oshaughne...@sun.com:Strategic Applications Engineering, Austin
Texas:512-401-1070
---
erik.oshaughne...@sun.com:Strategic Applications Engineering, Austin
Texas:512-401-1070
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
