Messages in this thread |  | | Date | Sun, 4 Nov 2001 20:45:02 +0100 | From | Jakob Østergaard <> | Subject | Re: PROPOSAL: dot-proc interface [was: /proc stuff] |
| |
On Sun, Nov 04, 2001 at 07:24:36PM -0000, Alex Bligh - linux-kernel wrote: > > > --On Sunday, 04 November, 2001 8:04 PM +0100 Jakob Østergaard > <jakob@unthought.net> wrote: > > > I'm a little scared when our VFS guy claims he never heard of excellent > > programmers using scanf in a way that led to parse errors. > > I'd be far more scared if Al claimed he'd never heard of excellent > programmers reading binary formats, compatible between multiple > code revisions both forward and backwards, endian-ness etc., which > had never lead to parse errors of the binary structure.
Sure there is potential for error anywhere. And maybe your compiler's type-check is broken too. But that's not an argument for not trying to improve on things.
Please tell me, is "1610612736" a 32-bit integer, a 64-bit integer, is it signed or unsigned ?
I could even live with parsing ASCII, as long as there'd just be type information to go with the values. But I see no point in using ASCII for something intended purely for machine-to-machine communication.
/proc text "GUI" files will stay, don't worry :)
> If you feel it's too hard to write use scanf(), use sh, awk, perl > etc. which all have their own implementations that appear to have > served UNIX quite well for a long while.
Witness ten lines of vmstat output taking 300+ millions of clock cycles.
> Constructive suggestions: > > 1. use a textual format, make minimal > changes from current (duplicate new stuff where necessary), > but ensure each /proc interface has something which spits > out a format line (header line or whatever, perhaps an > interface version number). This at least > means that userspace tools can check this against known > previous formats, and don't have to be clairvoyant to > tell what future kernels have the same /proc interfaces.
Then we have text strings as values - some with spaces, some with quotes in them. Then we escape our way out of that (which isn't done today by the way), and then we start implementing a parser for that in every /proc using application out there.
These interfaces need to be "correct", not "mostly correct".
Example: I make a symlink from "cat" to "c)(t" (sick example, but that doesn't change my point), and do a "./c)(t /proc/self/stat":
[albatros:joe] $ ./c\)\(a /proc/self/stat 22482 (c)(a) R 22444 22482 22444 34816 22482 0 20 0 126 0 0 0 0 0 14 0 0 0 24933425 1654784 129 4294967295 134512640 134525684 3221223504 3221223112 1074798884 0 0 0 0 0 0 0 17 0
Go parse that one ! What's the name of my applications ?
It's good enough for human readers - we have the ability to reason and make qualified quesses. Now go implement that in every single piece of /proc reading software out there :)
If you want ASCII, we should at least have some approved parsing library to parse this into native-machine binary structures that can be used safely in applications. I see little point in ASCII then, but maybe it's just me.
> > 2. Flag those entries which are sysctl mirrors as such > (perhaps in each /proc directory /proc/foo/bar/, a > /proc/foo/bar/ctl with them all in). Duplicate for the > time being rather than move. Make reading them (at > least those in the ctl directory) have a comment line > starting with a '#' at the top describing the format > (integer, boolean, string, whatever), what it does. > Ignore comment lines on write. > > 3. Try and rearrange all the /proc entries this way, which > means sysctl can be implemented by a straight ASCII > write - nice and easy to parse files. Accept that some > /proc reads (especially) are going to be hard.
I just hate to implement a fuzzy parser with an A.I. that makes HAL look like kid's toys, every d*mn time I need to get information from the system.
I'm not a big fan of huge re-arrangements. I do like the idea of providing a machine-readable version of /proc.
-- ................................................................ : jakob@unthought.net : And I see the elder races, : :.........................: putrid forms of man : : Jakob Østergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |