RFC: /proc key naming consistency

RFC: /proc key naming consistency

[Mark Swanson]

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

Re: RFC: /proc key naming consistency

[Cameron Simpson]

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"

Re: RFC: /proc key naming consistency

[H. Peter Anvin]

Followup to:  <20020213030047.8B1FB2257B@www.webservicesolutions.com>
By author:    Mark Swanson <swansma@yahoo.com>
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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: RFC: /proc key naming consistency

[Daniel Phillips]

On February 13, 2002 09:07 pm, H. Peter Anvin wrote:
> Followup to:  <20020213030047.8B1FB2257B@www.webservicesolutions.com>
> By author:    Mark Swanson <swansma@yahoo.com>
> 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

Re: RFC: /proc key naming consistency

[H. Peter Anvin]

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

Re: RFC: /proc key naming consistency

[Luke Burton]

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

Re: RFC: /proc key naming consistency

[Miquel van Smoorenburg]

In article <Pine.LNX.4.33.0202141020140.5260-100000@dbsydn2001.aus.deuba.com>,
Luke Burton  <luke.burton@db.com> 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

Re: RFC: /proc key naming consistency

[Wichert Akkerman]

In article <a4ga1d$jov$1@ncc1701.cistron.net>,
Miquel van Smoorenburg <miquels@cistron.nl> 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     \
| wichert@wiggy.net                   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: RFC: /proc key naming consistency

[Vince Weaver]

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
 \/__\/__\/   vince@deater.net    http://www.deater.net/weave

Re: RFC: /proc key naming consistency

[ertzog]

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

Re: RFC: /proc key naming consistency

[Alexander Viro]

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.