Messages in this thread |  | | Date | Tue, 01 Oct 1996 00:07:45 -0600 (MDT) | From | Rob Riggs <> | Subject | Re: proposal for generic interface to /proc text files |
| |
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)
|  |