Re: proposal for generic interface to /proc text files

Rob Riggs (rriggs@tesser.com)
Tue, 01 Oct 1996 00:07:45 -0600 (MDT)

On 01-Oct-96 Tyson D Sawyer wrote:
>A good adaptable interface doesn't need backwards compatitbility,
>as is the case of tagged entries. The backwards compatibility
>in this case comes from the flexibility of a fixed interface rather
>than playing with different interfaces and having to know which one
>it is.

True, but it requires all of the developers to be writing
proc entries the same way. I like the idea of a uniform
proc interface (for aesthetic reasons only), but abhore
the imbedded tags idea. I think one file, distributed with
the kernel and describing the current proc layout, is best.
That might even make a libproc feasible. Heck, if both were
done correctly, changing the default proc mount point (as is
also being discussed) could occur with no ill effect.

You could do something like:

# cpuinfo
# proc file header
ProcCpuInfo: /proc/cpuinfo mutli_record format_type_1
# LabelID: file label datafield type
CpuId: ProcCpuInfo "processor" 3 int
CpuType: ProcCpuInfo "cpu" 3 int # string?
CpuModel: ProcCpuInfo "model" 3 string
CpuVendor: ProcCpuInfo "stepping" 3 int
CpuFdivBug: ProcCpuInfo "fdiv_bug" 3 yes_no
.
.
.

A means of describing the proc filesystem is a good idea.
Imbedding tags is ugly and limited. If the current structure
of proc changes or the mount point is moved you are still
SOL with tagged fields. In this case an external means of
describing where each entry is and the kind of data to expect
is the way to go.

Rob
(rriggs@tesser.com)