Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)

Alexander Viro (viro@math.psu.edu)
Wed, 25 Apr 2001 18:42:33 -0400 (EDT)


On Thu, 26 Apr 2001, J . A . Magallon wrote:

>
> On 04.25 Doug McNaught wrote:
> > "J . A . Magallon" <jamagallon@able.es> writes:
> >
> > > Question: it is possible to redirect the same fs call (say read) to
> > different
> > > implementations, based on the open mode of the file descriptor ? So, if
> > > you open the entry in binary, you just get the number chunk, if you open
> > > it in ascii you get a pretty printed version, or a format description like
> >
> > There is no distinction between "text" and "binary" modes on a file
> > descriptor. The distinction exists in the C stdio layer, but is a
> > no-op on Unix systems.
> >
>
> Yep, realized after the post, fopen() is a wrapper for open(). The idea
> is to (someway) set the proc entry in verbose vs fast-binary mode for
> reads. Perhaps an ioctl() or an fcntl() or something similar.
> So the verbose mode gives the field names, and the binary mode just
> gives the numbers. Applications that know what are reading can just
> read binary data, and fast.

OK, _what_ applications spend a considerable time (and considerable
percentage of the total execution time) parsing stuff in /proc?
ps(1)? top(1)? Fine. They touch how many files outside of /proc/<pid>/* ?
Exactly.

_Please_, drop this idiotic "parsing ASCII is slow" strawman. Or show some
valid examples.

-
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/