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

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

[Kervin Pierre]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[J . A . Magallon]

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.
> 
> ?
> 
> 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.

-- 
J.A. Magallon                                         $> cd pub
mailto:jamagallon@able.es                             $> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Albert D. Cahalan]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[elijah wright]

> 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

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/