[...] > Hence, I totally agree with... > > >If a reasonably stable filesystem-like interface was > available for > >prtconf-like data, it would be easy to build tools > which would look at > > >configuration and then subscribe to kstats to > produce correlated > >activities, just like prstat does with processes and > projects. > > ...both because the API might be simpler and the > process itself may take > less resources. > > I'll respond to individual concerns in their own > threads. > > This email and any files transmitted with it are > confidential and intended solely for the use of the > individual or entity to whom they are addressed. If > you have received this email in error please notify > the system manager. This message contains > confidential information and is intended only for the > individual named. If you are not the named addressee > you should not disseminate, distribute or copy this > e-mail.
>From my point of view, function-call-like APIs that deal with binary data, preferably available in both C and perl (the latter for those for whom everything has to be some sort of script), are preferable to new _text_ pseudo files that then need to be parsed from text back to something machine readable, which for particularly _human_ readable formats, may not be both efficient and unambiguous. (along those lines, it would be handy if there were a ksh93 extension that could map C data structures to ksh93 nested variables (using the API for the memory model of the ksh93 binary), not unlike what can be done for perl like that) OTOH, for existing things, (mnttab, sharetab), a file-like interface moved into the kernel avoids breaking existing scripts while sometimes being worth the bother by improving efficiency, correctness, or both. I don't have a problem with structured /proc as it exists on Solaris, because the files correspond to binary data structures (unambiguous and efficient), and /proc on Solaris has not become a random dumping ground. This message posted from opensolaris.org _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
