Linux-kernel mailing list archive 2000-15,: Re: Suggested dual human/binary interface for proc/devfs

# Re: Suggested dual human/binary interface for proc/devfs

Pierre Fortin (pfortin@SkyBest.com)
Tue, 11 Apr 2000 12:37:51 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Jan-Simon Pendry: "Re: Suggested dual human/binary interface for proc/devfs"
- Previous message: Andrea Arcangeli: "Re: zap_page_range(): TLB flush race"

Hi,

I just joined the list a last night; so I hope this idea has not already
been discussed and trashed, or totally off-topic... :^)

In my last role, I was looking at a number of ways to address the
human/machine readable problem space... without getting into all the
ways this can be done, there was one way which might be useful here
(based on the few messages I've seen so far).

The idea is quite simple actually. Maintain an [existing] internal
binary structure and modify the output *formatter* so that it can be
read by both the human AND machine *without* a separate parsing step...

Say what?!!! :^)

The way I see it, this is really just about a set of printf()'s... and,
using the existing capabilities of the scripting languages or their
modules.

Some postings I read were already very close... Consider:

/sbin/proc [ --python | --perl | --xml | ... ] [ structure ] > foo

with the output "looking like":

- Python code: no parsing necessary; "import foo" brings it
into the script as normal assignments... voila!
- Perl code: no parsing necesary; "include|require foo" <ditto>

Both of those formats are already human readable as:
var = value
(including arrays, dictionaries, lists, etc)

XML is a tad more verbose; but it still "fits the pattern"...

Just an idea... hmm... can Python do "import <stdin>"...? Perl?

HTH,
Pierre

Ed Carp wrote:
>
> 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.
>
> -
> 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/

-
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/

- Next message: Jan-Simon Pendry: "Re: Suggested dual human/binary interface for proc/devfs"
- Previous message: Andrea Arcangeli: "Re: zap_page_range(): TLB flush race"