lkml.org 
[lkml]   [2002]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: RFC: /proc key naming consistency
Date
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.284 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site