mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Miquel van Smoorenburg" <miquels@cistron.nl>
To: linux-kernel@vger.kernel.org
Subject: Re: RFC: /proc key naming consistency
Date: Thu, 14 Feb 2002 12:19:57 +0000 (UTC)	[thread overview]
Message-ID: <a4ga1d$jov$1@ncc1701.cistron.net> (raw)
In-Reply-To: <Pine.LNX.4.33.0202141020140.5260-100000@dbsydn2001.aus.deuba.com>

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


  reply	other threads:[~2002-02-14 12:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-13 23:31 Luke Burton
2002-02-14 12:19 ` Miquel van Smoorenburg [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2002-02-13  2:50 Mark Swanson
2002-02-13  5:00 ` Cameron Simpson
2002-02-13 20:07 ` H. Peter Anvin
2002-02-13 20:52   ` Daniel Phillips
2002-02-13 21:04     ` H. Peter Anvin

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='a4ga1d$jov$1@ncc1701.cistron.net' \
    --to=miquels@cistron.nl \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®