RFC: /xproc -> /proc files in xml grammer?

DISCUSSION Kervin Pierre 4 participants 4 messages Jan 3, 2001 – Jan 4, 2001

Share & tools

Kervin Pierre

author

2001-01-03 23:03 UTC #0 lore raw

hello,

Would XML be considered human readable enough for /proc files? If not, how about a /xproc filesystem ( maybe as a kernel build option ), same as /proc but uses an xml grammer for reporting.
I can see tons of uses for this, no more 'fuzzy' parsing for gui configuration tools, resource monitors, etc.

just thinking aloud really,
-Kervin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

J . A . Magallon

2001-01-03 23:39 UTC #1 lore raw

Quoted 9 lines · On 2001.01.04 Kervin Pierre wrote:

hello,
Would XML be considered human readable enough for /proc files? If not, how about a /xproc filesystem ( maybe as a kernel build option ), same as /proc but uses an xml grammer for reporting.
I can see tons of uses for this, no more 'fuzzy' parsing for gui configuration tools, resource monitors, etc.

Quoted 3 lines

?
just thinking aloud really,

More aloud thinkin...

I have seen some times this thread appear on the list. One of the
problems: you will have to force drivers to register in two file systems...

Perhaps there are tools yet to do what I'm thinkin of: a ghost file system that just mirrors /proc, changing format of output.

Say you clone the procfs to a fake fs driver (for example, procfs.xml) that just translates each fs access system call to

/fproc/xml/path/to/file_or_dir (fproc==formatted proc)

/proc/path/to/file_or_dir

reads its contents and reformats them to give the desired output (now thinkin on read-only, main people interest seems to be in syntax-ing the out of /proc).

So actual /proc stays, not breaking anything, and theres a way to write proc info formatters.

Even there could be many common code between all the possible procfs.XXXX things to ease maintenance.

Signature · 9 lines

J.A. Magallon                                         $> cd pub
mailto:[email protected]                             $> more beer

Linux werewolf 2.2.19-pre6 #1 SMP Wed Jan 3 21:28:10 CET 2001 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Albert D. Cahalan

2001-01-04 00:26 UTC #2 lore raw

In reply to Kervin Pierre

Quoted 5 lines

Would XML be considered human readable enough for /proc files? If not, how about a /xproc filesystem ( maybe as a kernel build option ), same as /proc but uses an xml grammer for reporting.
I can see tons of uses for this, no more 'fuzzy' parsing for gui configuration tools, resource monitors, etc.

No.

No XML. No colons. No newlines. No embedded whitespace. No quoting. No field names. No other screwing around.

Option 1 looks like this: 42 8842 0 4234 898 33 221 2512

Option 2 is a raw array of 64-bit binary data

Anything else, and somebody like you will be tempted to muck with it. We've seen spelling changes and column alignment break things. We've seen parsers break on /proc/cpuinfo because someone decided whitespace and extra columns might be nice. XML wouldn't be immune to the recent "features" vs. "flags" problem, but the two options above are.

Now, what is your problem? Grab libgtop (GPL) or libproc (LGPL) and be happy. All of "ps" is in fact under the LGPL, so you can grab anything else you might need. (LGPL: not just for libraries anymore)

You get libproc and ps here: http://www.cs.uml.edu/~acahalan/procps/
(maybe wait a week or two before you grab that -- new one coming)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/