From: joeja@mindspring.com
To: ebiederm@xmission.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Re: /proc & xml data
Date: Mon, 30 Oct 2000 13:17:03 -0500 [thread overview]
Message-ID: <Springmail.105.972929823.0.26378900@springmail.com> (raw)
Um, I'd have to say that putting one value in a file with a directory as a grouping would probably be a nightmare to maintain as well as navigate through. In essance you could end up with more files in the /proc than on the rest of the filesystem filesystem (excluding the /dev dir). It would start to have the whole proc tree look like something from /proc/sys/net/ipv4. Although the /proc/sys/net/ipv4 probably needs to have one value in a file as some of these are settable on from the console, other fiels that are not changable (like /proc/meminfo, proc/cpuinfo etc) would be a waste in one value per file.
Isn't the /proc supposed to be a 'friendly' interface into the kernel?
Anyway it was a more of a question.
> I
> was wondering if anyone had ever considered storing some of the data in
> xml format rather than its current format? Things like /proc/meminfo
> and cpuinfo may work good in this format as then it would be easy to
> write a generic xml parser that could then be used to parse any of the
> data. "MemTotal: %8lu kB\n"
>
> In the case of the meminfo it would be a matter of changing the lines in
> fs/proc/array.c function get_meminfo(char * buffer) from
>
> "MemTotal: %8lu kB\n"
>
> to something like
>
> "%8lu kB\n"
The general consensus is that if we have a major reorganization, in proc
the rule will be one value per file. And let directories do the grouping.
Eric
-
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/
reply other threads:[~2000-10-30 18:18 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Springmail.105.972929823.0.26378900@springmail.com \
--to=joeja@mindspring.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.