On Mon, Jul 09, 2007 at 11:14:18PM -0700, Alexander Kolbasov wrote:
> Hi Brendan,
>
> can I summarize your point as a proposal to extend kstat framework
> instead of providing filesystem-based representation for CPU-related
> information?
Yes, as a suggestion moving to a prototype. If this approa
On Jul 10, 2007, at 1:57 PM, Alexander Kolbasov wrote:
> I'd like to modify my initial proposal and suggest to create a "CPU
> Observability" project with the goal of providing good abstraction and
> tools for CPU-related observability.
>
> As for the exact mechanism being used - the filesystem, p
Bruce Shaw <[EMAIL PROTECTED]> wrote:
BS> I want in on this. I use kstat to derive CPU information for net-snmp.
BS> If we're opening the API, I've got some suggestions.
Bruce,
what are your suggestions?
- akolb
___
perf-discuss mailing list
>One question to consider is do we want to also
> support something similar to Linux's
> "/proc/cpuinfo"?
"something similar" might be up for discussion, but it's been
said before that unlike Linux, /proc on Solaris is _not_ a dumping
ground for every random piece of system info (worse yet, presen
On Tue, Jul 10, 2007 at 11:49:48AM -0600, Bruce Shaw wrote:
> >The kstat facility has long been in need of a serious overhaul; this
> >presents a good opportunity to do this work.
>
>
> I want in on this. I use kstat to derive CPU information for net-snmp.
> If we're opening the API, I've got s
>The kstat facility has long been in need of a serious overhaul; this
>presents a good opportunity to do this work.
> - Bryan
I want in on this. I use kstat to derive CPU information for net-snmp.
If we're opening the API, I've got some suggestions.
This email and any files transmitted wi
On Tue, Jul 10, 2007 at 10:57:17AM -0700, Alexander Kolbasov wrote:
> I'd like to modify my initial proposal and suggest to create a "CPU
> Observability" project with the goal of providing good abstraction and
> tools for CPU-related observability.
>
> As for the exact mechanism being used - the
I'd like to modify my initial proposal and suggest to create a "CPU
Observability" project with the goal of providing good abstraction and
tools for CPU-related observability.
As for the exact mechanism being used - the filesystem, programmatic
API, kstat extensions or some combination of these -
On Jul 10, 2007, at 11:33 AM, Richard Lowe wrote:
> Alexander Kolbasov <[EMAIL PROTECTED]> writes:
>
>> Richard Lowe <[EMAIL PROTECTED]> wrote:
> .many sage observations from both elided...
> Ah, it was using a web of symlinks to cross branches that I was
> missing.
>
>> I do not quite see
Alexander Kolbasov <[EMAIL PROTECTED]> writes:
> Richard Lowe <[EMAIL PROTECTED]> wrote:
>
> >> Currently some CPU-related information can be obtained using
> >> prtconf(1M) and psrinfo(1M) which just a wrapper around the kstat (1M)
> >> framework. The kstat framework is usable for rep
>I do not quite see how kstats can be used to represent trees. What do
you have in mind here?
Should we be thinking of a structure similar to that used by prtpicl?
There is information reported there not available in kstat.
If we are attempting to report this information using SNMP, its MIB
stru
Richard Lowe <[EMAIL PROTECTED]> wrote:
>> Currently some CPU-related information can be obtained using
>> prtconf(1M) and psrinfo(1M) which just a wrapper around the kstat (1M)
>> framework. The kstat framework is usable for representing simple
>> "flat" CPU properties, but using
12 matches
Mail list logo
