rpc.kstatd: Remote Kstat Access Service [PSARC/2008/502 FastTrack timeout 08/13/2008]

[James Carlson]

Andrew Gabriel writes:
> I think the right way is to identify the data you need, which kstats or 
> some other mechanism might provide (that's a local implementation detail 
> on the server, which can change), and then create a stable versioned 
> interface to that data.

That's essentially what we've been discussing by various means
(creating a MIB would be one way to do just that), but the original
author's motivation was to make *all* kstats -- both those existing
now and all in the future -- available in bulk.

As long as there's no identification of the specific data needed,
there's no good way to enumerate what needs to be nailed down.  Either
the documentation for this new feature needs to point out the risks
inherent in relying on the data without specific documentation of the
stability of the kstats in use, or a different solution is needed.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677