Ed Carp writes:
> George Bonser (grep@shorelink.com) writes:
>
> > Ok, I am completely miscommunicating to you. That format is NEVER intended
> > to be seen by a user (though they can get it if they want it). In this
> > case the output of
>
> I think we are, as Sir Arthur Conan Doyle might write, at cross-purposes.
>
> I believe the idea behind /proc is to allow anyone access to ASCII data
> regarding the kernel, including being easily readable by humans. My point
> was that the data in /proc should be easily parseable with a simple
> mechanism such as a shell script as well. I think Mike Porter was on the
> right track.
>
> If you want to take the stuff in /proc and present it as XML or HTML
> in a web page is completely up to you - in fact, it's a cool idea.
> But the data itself in /proc shouldn't be in XML or any other sort
> of specialized format.
Agreed. The whole point of having ASCII rather than binary exported
from the kernel is so that it's easily read by humans and *Bourne*
shell scripts with standard Unix tools. That means no Perl, no xyz
utility.
If we're not going to support that, then we should go straight binary
instead. Pseudo-ASCII is worse than no ASCII.
And consider this: if we were to go with XML or whatever the latest
toy is for procfs output, for consistency we should also have XML
input. That means an XML parser in the kernel. And that is a really,
really bad idea. Whatever we have in the kernel should be simple.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:16 EST