Erik O'Shaughnessy writes: > The pNFS team has expressed interest in this project and I understand > they were/are considering implementing something similar. There has > also been interest expressed from engineers in PAE in utilizing this > service in their efforts as well, however no formal commitment to use > rpc.kstatd has been made by either party. I'm anticipating that this > will be a case of "If you build it, they will come".
"None" would have worked here. I was fishing to see if there were specific requirements that those users might have -- something that could help clarify this project. > I perhaps have made a tactical mistake in presenting the RPC service > ahead of the changes to libkstat. The current proposal specifically > does not preclude the addition of methods for obtaining kstat data. I didn't think that it would. > 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? 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. (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?) > > The current libkstat is in the root file system (/lib) and links > > against just libc and libm. What does the new one require? > > > > The new libkstat will require libnsl (which also resides in /lib) in > order to use clnt_create(), clnt_call(), XDR functions, and hostname > resolution. I am guessing that I should have included that in the > "Imported Interfaces" section of the proposal. OK; thanks. I was checking to see that the dependencies were thought through. -- 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
