RFC: /xproc -> /proc files in xml grammer?
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/
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)
to
/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/
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/
OT Re: RFC: /xproc -> /proc files in xml grammer?
Quoted 5 lines
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/cpuinfobecause someone decided whitespace and extra columns might be nice. XML wouldn't be immune to the recent
lol... i think this is worthy of a "kernel list newbie alert"...
WOOOOT! WOOOT! KERNEL LIST NEWBIE!!!!
:)
~elijah
-
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/