[this got bounced by the email interface: inserted via the gui]
Alexander Kolbasov wrote:
> Hi Brendan,
[...]
I'd like to suggest that kstats are excellent for handling a hierarchy
of rapidly-changing data, and produce the raw data that needs to be
correlated to discuss, for example, L3 cache.
They are less suitable for describing the relationship of devices
to one another, and I notice that is done with tools like prtconf, which
walk a hierarchy and report it in fa form suitable for static analysis.
For example, a colleague (Vladimir Dragiev, then at Sun) wrote a
prtconf-based test for excessive disks on a scsi controller, to prove
customers were misconfiguring their systems.
If a reasonably stable filesystem-like interface was available for
prtconf-like data, it would be easy to build tools which would look at
configuration and then subscribe to kstats to produce correlated
activities, just like prstat does with processes and projects.
By "reasonably stable", by the way, I don't mean immutable
(the ABI sense of "standard"). I merely mean one which has the
same controlled mutation characteristics as a Codd/Date relation:
one can define an obsolete entry as NULL, and one can add
new entries "at the right-hand end". Readers can then adapt to
changes programmatically.
Without a reasonably stable interface, one is left parsing prtconf
output or inventing one's own. That discourages one from building
tools which do the correlation. And that's A Bad Thing (;-))
--dave (formerly of the ABI team) c-b
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net | -- Mark Twain
(416) 223-5943
--
This messages posted from opensolaris.org
