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().
Fire away...
On 21:50 12 Feb 2002, Mark Swanson <[email protected]> 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 [email protected] 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"
Followup to: <20020213030047.8B1FB2257B@http://www.webservicesolutions.com>
By author: Mark Swanson <[email protected]>
In newsgroup: linux.dev.kernel
>
> 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().
>
When I and Dan Quinlan submitted the cleanup for this we used _
everywhere. Unfortunately some other people not just added keys with
spaces, but gracefully "corrected" our "mistakes"...
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On February 13, 2002 09:07 pm, H. Peter Anvin wrote:
> Followup to: <20020213030047.8B1FB2257B@http://www.webservicesolutions.com>
> By author: Mark Swanson <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > 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().
> >
>
> When I and Dan Quinlan submitted the cleanup for this we used _
> everywhere. Unfortunately some other people not just added keys with
> spaces, but gracefully "corrected" our "mistakes"...
What do you think about the idea earlier in this thread of going with
shell-parsable key value pairs? I find that idea really attractive, but
there's the issue of breaking utilities (kde control panel?) that already
parse the existing format.
--
Daniel
Daniel Phillips wrote:
>
> What do you think about the idea earlier in this thread of going with
> shell-parsable key value pairs? I find that idea really attractive, but
> there's the issue of breaking utilities (kde control panel?) that already
> parse the existing format.
>
I like the idea. Unfortunately I think it's more than kde that's going to
break.
-hpa
> What do you think about the idea earlier in this thread of going with
> shell-parsable key value pairs? I find that idea really attractive,
> but there's the issue of breaking utilities (kde control panel?) that
> already parse the existing format.
Shell parseable /proc/* entries would be so much more elegant to deal with
compared to the old system. I would guess that maintainers for things like
KDE would jump at the opportunity to decrease the complexity of their
code.
A compatibility mode might be useful. Either a straight config option, or
perhaps something more sophisticated. Idea: perhaps proc functions
installed with create_proc_read_entry could, rather than just write
strings to buffers, return a list of key/value pairs which is rendered in
some configurable format by a new function, like "proc_render_values".
proc_render_values could use a column format like it does now, or a shell
parseable foo=blah\n format.
Or even XML. Ouch! No need to throw things at me!
Regards,
Luke.
--
Ash OS durbatulk, ash OS gimbatul,
Ash OS thrakatulk, agh burzum-ishi krimpatul!
Uzg-Microsoft-ishi amal fauthut burguuli.
In article <[email protected]>,
Luke Burton <[email protected]> wrote:
>A compatibility mode might be useful. Either a straight config option, or
>perhaps something more sophisticated. Idea: perhaps proc functions
>installed with create_proc_read_entry could, rather than just write
>strings to buffers, return a list of key/value pairs which is rendered in
>some configurable format by a new function, like "proc_render_values".
>proc_render_values could use a column format like it does now, or a shell
>parseable foo=blah\n format.
Why not one value per file, as has been proposed often here.
You could have /proc/sys/cpu/0/processor
/proc/sys/cpu/0/vendor_id
/proc/sys/cpu/0/family
... and a /proc/sys/cpu/0/.table that when read produces
processor=0
vendor_id=GenuineIntel
family=6
.. so you have the best of both worlds. And you could support a
sysctl() system call that reads out the same value *in binary*
so you don't need the printf() -> sscanf() conversion.
The current sysctl_args struct does need an extra "oldtype" and "newtype"
value in there, which could be set to SYSCTL_TYPE_IP, SYSCTL_TYPE_INT4,
SYSCTL_TYPE_STRING, etc and which could be ORed with SYSCTL_FMT_ASCII
or SYSCTL_FMT_BINARY
sysctl also needs a way to get an entire tree (the .table entry)
in just one call.
So I advocate having /proc and sysctl() being just 2 ways to access
the same namespace, having one value per file, and having a way
to read a entire tree or directory at once.
Mike.
--
Computers are useless, they only give answers. --Pablo Picasso
In article <[email protected]>,
Miquel van Smoorenburg <[email protected]> wrote:
>You could have /proc/sys/cpu/0/processor
> /proc/sys/cpu/0/vendor_id
> /proc/sys/cpu/0/family
>
>... and a /proc/sys/cpu/0/.table that when read produces
And then instead of using those names use standard MIB names and add
symlinks for assigned OID numbers and we can do SNMP using netcat
and a sh script.
Wichert.
--
_________________________________________________________________
/ Nothing is fool-proof to a sufficiently talented fool \
| [email protected] http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
> Or even XML. Ouch! No need to throw things at me!
>
> Regards,
It seems they would be thrown! XML in kernel is too much. OpenOffice and
GNOME/KDE are enough. This "unexpected expirience" in free software world
are just mosters because of this damn standart XML. Of course it is nice,
but using it is TOO slow.
On Thu, 14 Feb 2002, Luke Burton wrote:
> Shell parseable /proc/* entries would be so much more elegant to deal with
> compared to the old system. I would guess that maintainers for things like
> KDE would jump at the opportunity to decrease the complexity of their
> code.
as a maintainer of "linux_logo" which delves heavily (and perhaps
unwisely) into /proc/cpuinfo and its ilk, I would definitely say I would
not be jumping at the opportunity.
Remember as maintainers of userspace apps, we have to keep compatibility,
in this case for me it involves /proc/cpuinfo from all the architectures,
plus kernels going back to the 1.2.13 time-frame.
So changing /proc/cpuinfo yet again does not simplify the code, in fact it
just adds one more incompatible special case.
And since 2.2 and 2.4 kernels will be around for ages to come, it will
make code bigger rather than smaller.
I agree a cleanup, if done properly, would be welcomed. but don't use
"simplification of user-space code" as an argument.. because it's a lie ;)
Vince
who is perhaps bitter because of all the gratuitious "spaces.. no, tabs..
no, underscores" and "bogomips BOGOmips BogoMips BoGoMiPs bobo_mips" type
changes over the years
--
____________
\ /\ /\ / Vince Weaver Linux 2.4.17-rc1 on a K6-2+, Up 59 days
\/__\/__\/ [email protected] http://www.deater.net/weave
On Thu, 14 Feb 2002, ertzog wrote:
> > Or even XML. Ouch! No need to throw things at me!
> >
> > Regards,
>
> It seems they would be thrown! XML in kernel is too much. OpenOffice and
They won't be thrown. They will be slowly driven under the nails, so that
victim could experience the joy equal to that of dealing with XML.