Re: proposal for generic interface to /proc text files

Keith Owens (kaos@audio.apana.org.au)
Tue, 1 Oct 1996 22:50:14 +1000 (EST)


On Tue, 1 Oct 1996, Rob Riggs wrote:
> 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.

You just added a field seperator ("/") to /proc output (a tag by any
other name is still a tag). What about conditional lines, not just
conditional fields? How is your descriptor file going to recognise that
a line is a subset or continuation of the previous line without some
marker? Or are we going to say that /proc developers cannot create
files in that format, even if it makes sense to the developer? E.g.

Primary record
Secondary record
Secondary record

> 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. :)

An approach I cannot agree with! Forcing all future /proc output into a
simple space delimitted fixed format because that is all the "parser"
can cope with is IMHO the wrong approach. We should go for as much
flexibility in /proc output as is reasonably possible and let the
developers chose the /proc output that suits the kernel code, not
restrict the way they can represent the data.