Stephen Hahn wrote:
> * Garrett D'Amore <[EMAIL PROTECTED]> [2007-03-06 14:36]:
>
>> Stephen Hahn wrote:
>>
>>> * Garrett D'Amore <[EMAIL PROTECTED]> [2007-03-06 14:03]:
>>>
>>>
>>>> This makes no sense to me. Its easy to iterate over all the stats and
>>>> dump them. The only time you have to change the code is when adding new
>>>> kstat types. (E.g. KSTAT_TYPE_INTR, etc.) This has only happened twice
>>>> since Solaris 2.5 that I'm aware of ... once to add 64-bit values, and
>>>> once again to provide a cleaner way to represent strings in kstats.
>>>>
>>>>
>>> You are neglecting the interpretation of kstats of type
>>> KSTAT_TYPE_RAW, each of which can be filled with the contents of an
>>> arbitrary structure and need not be present on all platforms.
>>>
>>> Each kstat dumper (that can display all kstats) must have a catalog of
>>> the structure definitions that are published as raw kstats.
>>>
>> To my knowledge, netstat -k never supported RAW kstats.
>>
>
> No, it did not. That was, in fact, one of the reasons to remove the
> undocumented, uncommitted functionality.
>
>
>> How does kstat(1) deal with RAW kstats? Can it?
>>
>
> Yes.
>
>
>> I've not looked at the source for the Kstat perl module, but to my
>> mind, if kstat(1) is going to deal with raw kstats, then the perl
>> module must have those structure definitions, and we're just talking
>> about semantics (since the knowledge of them has to live _somewhere_,
>> be it in a utility, a shared library, or a perl module...)
>>
>> >From looking at the output from kstat(1), I don't think it deals with
>> raw kstats either. At least I don't see any obvious ones in the
>> output.
>>
>
> $ kstat ::vminfo
> module: unix instance: 0
> name: vminfo class: vm
> crtime 0
> freemem 894957641357
> snaptime 578680.831075174
> swap_alloc 45722063002
> swap_avail 1075626259597
> swap_free 1087167234051
> swap_resv 57263037456
>
> I would agree that a project to rewrite kstat(1) in C requires
> investigation; in particular, an expected part of such a proposal
> would be a means of allowing access to raw kstats via the various APIs
> offered without simply having multiple copies of that information.
>
Hmmm.... that is interesting. Perl basically just dumps this out as
named values. I wonder if it is not an entirely insane idea that the
stats could have been supplied as KSTAT_TYPE_NAMED in the first place?
(I've always believed that raw kstats were for sharing data data
structures that were opaque. The very fact that kstat(1) unpacks these
makes them no longer opaque.)
Is there some compelling reason for these kstats to be RAW that I'm missing?
The funny thing is that the way these are exported back into userland
from the perl module makes it non-obvious that they are not named kstats
as it is.
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
