Messages in this thread |  | | Date | Tue, 1 Oct 1996 22:50:14 +1000 (EST) | From | Keith Owens <> | Subject | Re: proposal for generic interface to /proc text files |
| |
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.
|  |