> > I would like to propose a new "CPUfs" project aimed at providing
> > extended observability for the CPUs in the system and their sharing
> > relationships. The main objective is to provide stable infrastructure
> > for representing CPU properties for user-land applications.
> >
> > 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 it becomes more and more of a stretch
> > in the CMT world.
> >
> > The purpose of the CPUfs project is to explore using the file system
> > abstraction to represent CPU properties. File system abstraction
> > supports hierarchy and convenient name space.
> >
> > I suggest hosting the project under either Observability or
> > Performance community.
> >
>
> While I agree that greater observability here is desirable, it'd be
> good to see some rational as to why kstat can't provide it, and,
> beyond that, why a pseudo-fs is the better choice.
Just to echo Rich's comment, and a comment that others have made: I
really don't want to see a pseudofilesystem become a dumping ground for
machine information, in part because it makes for a terrible API. (Indeed,
this proposal is almost identical to the ill-fated "MachFS" proposal of
many years ago -- and this proposal suffers from many of the same problems.)
I would much rather see kstat extended to be able to track this kind of
information, and then a pseudofilesystem interface put on top of all of
kstat (which should have been done long ago, in my opinion). The
pseudofilesystem interface could even be human-readable -- as long as the
API allows me to get at the information in a rigorous and programmatic
manner.
The kstat facility has long been in need of a serious overhaul; this
presents a good opportunity to do this work.
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
