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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.