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

[Alexander Viro]

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

> 
> On 04.25 Doug McNaught wrote:
> > "J . A . Magallon" <[e-mail]> 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.