Erik O'Shaughnessy wrote:
>
> On Aug 6, 2008, at 4:00 PM, Nicolas Williams wrote:
>> On Wed, Aug 06, 2008 at 04:06:58PM -0400, James Carlson wrote:
>>> Erik O'Shaughnessy writes:
>>>> Addressing your question directly, I am not familiar with SNMP and a
>>>> quick perusal of the body of work available regarding SNMP seems to
>>>> contradict the "Simple" in Simple Network Monitoring Protocol. I see
>>>> no reason why SNMP would not be an acceptable mechanism for retrieving
>>>> kstat data, however I have not prototyped it.
>>>
>>> How do you plan to recreate the security features that exist in a more
>>> robust solution such as SNMP? Or is the new RPC-based feature usable
>>> only when the user doesn't care to have security?
>>
>> For RPC the obvious answer is RPCSEC_GSS, which wouldn't require any
>> changes to the kstat API -- the credentials are found in the user's
>> login environment.
>
> This is my fall back plan if Secure By Default was not secure enough.
>
>>> On a related note, what will the documentation say about the stability
>>> of the kstat entries themselves? Currently, most of the kstats in the
>>> system are undocumented and cannot safely be used by those writing
>>> applications. They may change incompatibly at any time. Worse still,
>>> there's no versioning at all in the interface, so you'll be at some
>>> disadvantage when you're reading kstats from a remote system.
>
> I had not planned on commenting on the stability of the kstat data.
> The only stability claims I could find ( kstat.3kstat ) were the value
> components for kstat_named_t. The rest of the kstat data types have
> no documented stability (that I could find).
>
>>> (Yes, of course, RPC itself has versioning, but you're not going to
>>> bump the version number each time someone modifies a kstat_create call
>>> in ON, are you?)
>>
>> Right, RPC versioning won't do here. Erik: do you need a procedure for
>> getting kstat version information from the remote system?
>
> Yes, this is a deficiency in my design and I will address it. I don't
> know how to correctly handle this off the top of my head but I will
> work on it.
My perception is that if you want to build on top of kstat's (outside of
debugging tools), you're probably building a house of cards -- kstats
simply aren't stable. The only ones that have any real notion of
"stability" behind are the ones that are likely already covered via
other APIs, such as rstat and SNMP.
If you need to have remote access to some form of "stable" data, I
wonder if either extending rstat, or using SNMP, might not be a better
choice.
The former has a relatively stable API (not sure about extending it,
though), and the latter is backed by multiple vendors and real standards.
Perhaps it would be instructive to have more information about what kind
of statistics you want remote access to.
-- Garrett
>
> -ejo
>
> ---
> Erik.Oshaughnessy at sun.com, x64070, 512-401-1070, SAE Austin
>
>
>
>
