/proc format (was Device Registry (DevReg) Patch 0.2.0)
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 11 lines · Jesse Pollard
Quoted 10 lines
But one thing XML provides (potentially) is a DTD that defines meanings and formats. IMHO the kernel needs something like this for /proc (though not in DTD format!).
Has anyone ever tried to write a formal syntax for all the entries
in /proc? We have bits and pieces of /proc documentation in/usr/src/linux/Documentation, but nothing you could feed directly into a parser generator. It'd be neat to have a good definition for /proc in the LSB, and have an LSB conformance test that could look in /proc and say "Yup, all the entries there conform to the spec and can be parsed properly."...
Quoted 4 lines
From one point of view (that of the /proc entries...) each file is by definition in the proper format. That format is specified (in the /proc interface to the driver). Using "
proc_printf" is a specification for the output.
When two different distributions ship different forks of
the kernel source, which differ in the arguments passed to proc_printf, which one is right?
There's no way to tell. That's why saying "the source is the spec" doesn't cut it.
Also, the source is not a specification a parser generator can use.
A formal spec for /proc entries maintained by e.g. the LSB is needed; it has to be separate from the source code (to avoid forking problems), and it should be machine-readable (so we can build parsers from it).
Quoted 8 lines
That DOES NOT mean that no improvements are possible. If the formats used by the various modules/drivers has some variation in format from access to acess, then the determination of that format must also be included. From what I've seen (via "cat
/proc/....") the files all have a fixed format. Sometimes the number of entries varies, but then the count should ALSO be included in the file (in a known place of course). The multi-entry files I've looked at (/proc/net) reach the EOF to end the list. This is not unreasonable.
Yeah, there's a general style that seems to work; it just needs to be formalized.
Quoted 4 lines
I'm not sure of the usefullness of the title lines that are printed. If looked at in raw form, yes the titles are nice. But the utilities that are aimed at examining the values should not have to discard them, nor should the drivers have to generate them.
I think they're good; they're a little bit like the XML tags you're proposing.
Quoted 4 lines
I can live with them anyway, since they are already there.....
The biggest problem I know of is being able to retrieve structure in an atomic manner. Not easy (in any system, not just Linux).
Something SNMP doesn't deal well with, either. People seem to cope, though.
- Dan