Richard Gooch (rgooch@ras.ucalgary.ca) writes:
> 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.
EXACTLY! Thanks for understanding :)
-
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