lkml.org 
[lkml]   [1996]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: proposal for generic interface to /proc text files

On 01-Oct-96 Keith Owens wrote:
>>On Tue, 1 Oct 1996, Rob Riggs wrote:
>> On 01-Oct-96 Tyson D Sawyer wrote:
>> >A good adaptable interface doesn't need backwards compatitbility,
>> >as is the case of tagged entries. [snip]
>
>> I think one file, distributed with the kernel and describing the current
>> proc layout, is best. [snip]
>
>Hidden assumption there. It requires that all fields in every /proc file
>appear every time, that is, it makes no allowance for conditional output.
>Some files *might* want to omit fields that do not apply to the current
>environment. A simple field by field proc descriptor file cannot cope with
>this format without some form of identifier in the files, which is where we
>came in.

That's just plain silly. If you *can* make the implementation
robust enough to deal with this.

Take /proc/cpuinfo as an example (again):

# cpuinfo
# proc file header
ProcCpuInfo: /proc/cpuinfo mutli_record format_type_1
# LabelID: file label datafield type
...
CpuFlags: ProcCpuInfo "flags" {
"fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
"cx8", "apic", "10", "11", "mtrr", "pge", "mca", "cmov",
"16", "17", "18", "19", "20", "21", "22", "mmx",
"24", "25", "26", "27", "28", "29", "30", "31" } bit_flags


>Of course we could mandate that all proc files display all their fields every
>time, i.e. no conditional output. We just need to be sure that we are happy
>with that decision.

That would not make sense in the above example.

Dropping an entire entry is easy to deal with. If a specific field
of an entry is dropped, that makes it difficult to parse no matter
what. So you know the data type. Big deal.

You could also have different format descriptors for the same
proc files. Find out which one matches the current state and go
on from there.

Just for sake of argument, let us suppose that /proc/loadavg does
not fill in the 5 minute load avg until we've been up 5 minutes
and does not fill in the 15 minute load avg until we've been up
15 minutes. We could have a descriptor for each of the following:

0.08 0.05 0.01 2/53 2385
0.08 0.05 2/53 2385
0.08 2/53 2385

Note the "/". That means we need to describe the field seperators.
But this is easy to do as well.

I am not saying that we should not change proc, only that is is
unnecessary. You are perceiving limitations where there are none.
That is not to say that some yahoo out there won't create a proc
file that is completely outside the scope of the final description
language. But if that happens, a little coersion can usually bring
conformity. :)

Rob
(rriggs@tesser.com)



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.039 / U:1.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site