public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Valdis.Kletnieks@vt.edu
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded
Date: Mon, 29 Jan 2007 01:24:57 -0700	[thread overview]
Message-ID: <m164aqme92.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <200701290645.l0T6jX0S030597@turing-police.cc.vt.edu> (Valdis Kletnieks's message of "Mon, 29 Jan 2007 01:45:33 -0500")

Valdis.Kletnieks@vt.edu writes:

> On Sun, 28 Jan 2007 23:08:17 MST, Eric W. Biederman said:
>> Valdis.Kletnieks@vt.edu writes:
>
>> Does it find sys?  If so perhaps I should do something even more significant.
>> I guess if I get many complaints about this I will figure out how to print
>> out an appropriate error message.
>
> It found sys, and then the second iteration in in xlate_proc_name it failed
> to find net because the de->subdir for sys/net wasn't set.

Thanks. 

>> > What's the intended semantics of create_proc_entry and xlate_proc_name in
>> > this new regime of no subdir pointers? Or am I just (yet again) one of the
>> > first to trip over a bug?
>> 
>> It is supposed to fail in this instance.  If you want something under
> /proc/sys
>> you are supposed to use register_sysctl like everyone else.  If it's not a
>> sysctl it should not show up under /proc/sys.
>
> Wasn't my code originally - I think the original author thought that since
> all the *other* config stuff for ipv4 was down under /proc/sys/net/ipv4, this
> one should be as well because that's where sysadmins would look for it, and
> wasn't thinking so much about whether it was a sysctl or not.
>
>> I'm glad to see my cleanup uncovering more bugs, I'm sorry you were the one
>> who had to find it.  I will you well fixing your out of tree ipfilter module.
>
> It's easy enough to move the entry under /proc/net or someplace instead.
>
> What's the current advice on what kernel interface to use for this scenario:
>
> In userspace, we do something like this:
>
> (while read foo; do echo $foo > /proc/my_file; done) < /etc/bunch_of_lines
>
> and we want to catch, parse, and save each line as it enters the kernel, and
> we end up with several dozen entries saved.
>
> If we do a 'cat /proc/my_file', we iterate across the list of saved lines
> and dump them all out.

Well it is a non-fixed number of entries so it does not sound appropriate for
a sysctl.  sysctl tends to work well for simple settings, not complicated things.

/proc/net would be the easy place, although I think traditionally /proc/net
is just reporting.

Given the context I will suggest setsockopt as most of iptables is configured
using that.

Generally going beyond one value per file is discouraged, in any context.

So I guess the general advice is don't have that scenario :)

In your situation I would find something in the kernel that does something
similar and see how it provides for a user interface.  If there is a way
that it is done for similar modules do that. 

If there is no precedent something under sysfs likely makes the most sense.
/proc is really supposed for things related to processes.

I usually spend my time keeping the old things going and useful in new and
interesting situations instead of figuring out the interface recommendation
of the week.

I would be really surprised if your configuration requirements were unique
and there weren't several somethings in the kernel that solved the
same problem in a different way.

Eric

  reply	other threads:[~2007-01-29  8:25 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200701260837.l0Q8blBr011622@shell0.pdx.osdl.net>
2007-01-26 15:04 ` mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded Michal Piotrowski
2007-01-26 15:33   ` Serge E. Hallyn
2007-01-26 15:38     ` Serge E. Hallyn
2007-01-26 16:06       ` Michal Piotrowski
2007-01-26 16:37 ` Michal Piotrowski
2007-01-26 16:46 ` Michal Piotrowski
2007-01-26 16:57 ` Michal Piotrowski
2007-01-26 17:29 ` Michal Piotrowski
2007-01-26 18:14   ` Serge E. Hallyn
2007-01-26 18:22     ` Michal Piotrowski
2007-01-26 18:58       ` Serge E. Hallyn
2007-01-26 17:48 ` Michal Piotrowski
2007-01-26 18:04 ` Michal Piotrowski
     [not found]   ` <6bffcb0e0701261008u2fd5a7d9va16d7fd9f250e14b@mail.gmail.com>
2007-01-26 18:38     ` Christoph Lameter
2007-01-26 18:43       ` Pavel Machek
2007-01-26 18:45       ` Michal Piotrowski
2007-01-26 19:07         ` Christoph Lameter
2007-01-26 19:20           ` Michal Piotrowski
2007-01-26 19:45 ` Michal Piotrowski
     [not found]   ` <6bffcb0e0701261523j3a84a357lad93260b5865c99d@mail.gmail.com>
2007-01-27  0:33     ` Andrew Morton
2007-01-27  0:41       ` Michal Piotrowski
2007-01-27  0:29 ` Michal Piotrowski
2007-01-27 15:05 ` Michal Piotrowski
2007-01-27 20:38   ` Herbert Xu
2007-01-27 16:03 ` Michal Piotrowski
2007-01-30  1:05   ` Tejun Heo
2007-01-27 16:14 ` Michal Piotrowski
2007-01-27 17:20 ` Michal Piotrowski
     [not found] ` <6bffcb0e0701270837i1ec40560l6e61e8876177e9da@mail.gmail.com>
2007-01-27 21:29   ` Tilman Schmidt
2007-01-27 21:41     ` Andrew Morton
2007-01-27 22:12       ` Michal Piotrowski
2007-01-27 23:25       ` Tilman Schmidt
2007-01-27 23:27         ` Michal Piotrowski
2007-01-28  2:41       ` Valdis.Kletnieks
2007-01-28  3:37         ` Michal Piotrowski
2007-01-29  2:49         ` Valdis.Kletnieks
2007-01-29  6:08           ` Eric W. Biederman
2007-01-29  6:45             ` Valdis.Kletnieks
2007-01-29  8:24               ` Eric W. Biederman [this message]
2007-01-29  2:58         ` Valdis.Kletnieks
2007-01-29  5:14           ` Randy Dunlap
2007-01-29  5:46           ` Valdis.Kletnieks

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=m164aqme92.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@osdl.org \
    --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