From: Amit Gud <agud@redhat.com>
To: Chase Venters <chase.venters@clientec.com>
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, deweerdt@free.fr
Subject: Re: [RFC] [PATCH] sysctl for the latecomers
Date: Tue, 01 Aug 2006 15:04:08 -0400 [thread overview]
Message-ID: <44CFA5A8.50105@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0608011213190.12077@turbotaz.ourhouse>
Chase Venters wrote:
> On Tue, 1 Aug 2006, Chase Venters wrote:
> Btw, wanted to add some comments on the specific approach:
>
> 1. A ring hard-coded to 32 elements is IMO unuseable. While it may not
> be a real limit for what use case you have in mind, if it's in the
> kernel sooner or later someone else is going to use it and get bitten.
> Imagine if they wrote in 33 entries, and the first one was some critical
> security setting that ended up getting silently ignored...
>
> 2. On the other hand, allowing it to grow unbounded is equally
> unacceptable without a mechanism to list and clear the current "pending"
> sysctl values. Unfortunately, at this point, you're starting to violate
> "KISS".
>
You figured it right, theres no "correct" number of elements that I
could adhere to.
> Are the modules you refer to inserted during init at all? Because it
> seems like it would be a lot more appropriate to just move sysctl until
> after loading the modules, or perhaps running it again once they are
> loaded.
>
I have a case where sunrpc module gets inserted and
sunrpc.tcp_slot_table_entries parameter is to be set _before_ nfs module
is inserted. I agree that for this particular case user-space works
(either udev rule, or modprobe.conf or sysctl after modprobe in
initscripts), but am on a lookout for a more generic way for handling
such cases - be it user-space or otherwise.
AG
--
May the source be with you.
http://www.cis.ksu.edu/~gud
next prev parent reply other threads:[~2006-08-01 18:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-01 14:49 [RFC] [PATCH] sysctl for the latecomers Amit Gud
2006-08-01 15:25 ` Frederik Deweerdt
2006-08-01 16:56 ` Chase Venters
2006-08-01 17:22 ` Chase Venters
2006-08-01 19:04 ` Amit Gud [this message]
2006-08-01 20:36 ` Chase Venters
2006-08-02 14:56 ` Horst H. von Brand
2006-08-01 17:41 ` H. Peter Anvin
2006-08-01 18:54 ` Andi Kleen
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=44CFA5A8.50105@redhat.com \
--to=agud@redhat.com \
--cc=chase.venters@clientec.com \
--cc=deweerdt@free.fr \
--cc=hpa@zytor.com \
--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