From: Cameron Simpson <cs@zip.com.au>
To: Mark Swanson <swansma@yahoo.com>
Cc: linux-kernel@vger.kernel.org,
Terrehon Bowden <terrehon@pacbell.net>,
Bodo Bauer <bb@ricochet.net>,
Jorge Nerin <comandante@zaralinux.com>
Subject: Re: RFC: /proc key naming consistency
Date: Wed, 13 Feb 2002 16:00:10 +1100 [thread overview]
Message-ID: <20020213160009.A7937@amadeus.home> (raw)
In-Reply-To: <20020213030047.8B1FB2257B@www.webservicesolutions.com>
In-Reply-To: <20020213030047.8B1FB2257B@www.webservicesolutions.com>
On 21:50 12 Feb 2002, Mark Swanson <swansma@yahoo.com> wrote:
| I would like to hear people's opinions on making the keys in the /proc
| hierarchy consistent wrt the space character. The current Linux
| Documentation/filesystems.proc.txt does not suggest any standard naming
| conventions. F.E. cat /proc/cpuinfo
| (partial list)
|
| cpu family : 5
| model : 9
| model name : AMD-K6(tm) 3D+ Processor
| stepping : 1
| cpu MHz : 400.907
| cache size : 256 KB
| fdiv_bug : no
| hlt_bug : no
| f00f_bug : no
|
| Notice the space between "cpu" and "MHz", or "cpu" and "family" yet there is
| no space between "fdiv" and "bug" (_).
|
| The reason I think NOT using a space is a good idea because it makes life
| easier for developers parsing /proc entries. Specifically, Java developers
| could use /proc/cpuinfo as a property file, but the space in the 'key' breaks
| java.util.Properties.load().
Personally, I have LONG wished all /proc/* entries were shell parsable values, eg:
cpu_family=5
model=9
model_name='AMD-K6(tm) 3D+ Processor'
etc. The amound of userland parsing code this would obviate must be quite
large, and it certainly would make simple scripts to do things with the
values much easier.
instead, there are all these "pretty" files, with formatting code that
properly belongs in userland tools residing in the kernel (yes, mostly
just printf but still).
Flame on dudes,
--
Cameron Simpson, DoD#743 cs@zip.com.au http://www.zip.com.au/~cs/
They call me a bummer and a gin-sop,too....but what care I for praise!
- Bob Dylan. "The days of '49"
next prev parent reply other threads:[~2002-02-13 4:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-13 2:50 RFC: /proc key naming consistency Mark Swanson
2002-02-13 5:00 ` Cameron Simpson [this message]
2002-02-13 20:07 ` H. Peter Anvin
2002-02-13 20:52 ` Daniel Phillips
2002-02-13 21:04 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2002-02-13 23:31 Luke Burton
2002-02-14 12:19 ` Miquel van Smoorenburg
2002-02-14 12:25 ` Wichert Akkerman
2002-02-14 16:09 ` Vince Weaver
2002-02-14 19:02 ` ertzog
2002-02-14 16:12 ` Alexander Viro
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=20020213160009.A7937@amadeus.home \
--to=cs@zip.com.au \
--cc=bb@ricochet.net \
--cc=comandante@zaralinux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=swansma@yahoo.com \
--cc=terrehon@pacbell.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox