Messages in this thread |  | | Date | Wed, 25 Apr 2001 18:42:33 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: /proc format (was Device Registry (DevReg) Patch 0.2.0) |
| |
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/
|  |