John Plocher writes: > When the Explorer cases went thru, we debated this > topic to death - and surmised that the only thing > this kind of data could be predictably used for > was collection for human perusal - any automated > use would require interaction with the team(s) that > created the kstats themselves to upgrade their > stability levels.
If "for human eyes only" is the goal, then you can already do what this project proposes, but with security, by "ssh hostname kstat". If you really don't care about security, enable rsh and use that. :-/ I doubt that "for human eyes only" is the goal here, particularly with the discussion in the original document about the Perl interfaces. This sounds to me like a general-purpose remote access mechanism for statistics, the kind that'll be baked into scripts and potentially into complex monitoring applications. It is indeed "simple" -- I'll grant the submitter that it's obviously the simplest way to implement such a mechanism -- but it's architecturally suspicious on the grounds that it's building atop an interface in a way that the designers of that interface didn't anticipate. It's analogous to scraping messages out of syslog files. The first time there's a bug fix that removes one of those kstats or redefines it, the applications that are using that variable will fail. We redefine these things all the time, and (like syslog messages) they're not typically considered "interfaces" of the sort that are architecturally controlled. Incompatible changes happen in patches. Do it if you want, I suppose, but building something that's going to be reliable and not cause avoidable escalations means providing suitably stable objects to access ... something like a MIB. I don't think this project (as defined) can do that. -- 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
