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/
This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:23 EST