On Sun, Nov 04, 2001 at 06:41:59PM +0100, Jakob Østergaard wrote:
> The "fuzzy parsing" userland has to do today to get useful information
> out of many proc files today is not nice at all. It eats CPU, it's
> error-prone, and all in all it's just "wrong".
This is because the files are human-readable, nothing to do with binary vs. plain
text. proc should be made (entirely ?) of value-per-file trees, and a back-compat
compatprocfs union mounted for the files people and programs are expecting.
> However - having a human-readable /proc that you can use directly with
> cat, echo, your scripts, simple programs using read(), etc. is absolutely
> a *very* cool feature that I don't want to let go. It is just too damn
> practical.
I don't see that it's at all useful: it just makes life harder. You yourself
state above that read(2) parsing of human readable files is "not nice at all",
and now you're saying it is "just too damn practical".
Just drop the human-readable stuff from the new /proc, please.
In what way is parsing /proc/meminfo in a script more practical than
cat /proc/meminfo/total ?
> > No, look, he's proposing to put the binary encoding in hidden .files. The
> > good old /proc files will continue to appear and operate as they do now.
> >
>
> Exactly.
This just seems needless duplication, and fragile. Representing things as directory
hierarchies and single-value files in text seems to me to be much nicer, just as
convenient, and much nicer for fs/proc/ source...
IMHO
john
-- "All this just amounts to more grist for the mill of the ill." - Elizabeth Wurtzel - 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