Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750865AbWHARW0 (ORCPT ); Tue, 1 Aug 2006 13:22:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750957AbWHARW0 (ORCPT ); Tue, 1 Aug 2006 13:22:26 -0400 Received: from relay03.pair.com ([209.68.5.17]:43781 "HELO relay03.pair.com") by vger.kernel.org with SMTP id S1751690AbWHARW0 (ORCPT ); Tue, 1 Aug 2006 13:22:26 -0400 X-pair-Authenticated: 71.197.50.189 Date: Tue, 1 Aug 2006 12:22:22 -0500 (CDT) From: Chase Venters X-X-Sender: root@turbotaz.ourhouse To: Chase Venters cc: Amit Gud , linux-kernel@vger.kernel.org Subject: Re: [RFC] [PATCH] sysctl for the latecomers In-Reply-To: Message-ID: References: <44CF69F0.6040801@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2102 Lines: 46 On Tue, 1 Aug 2006, Chase Venters wrote: > On Tue, 1 Aug 2006, Amit Gud wrote: > >> /etc/sysctl.conf values are of no use to kernel modules that are inserted >> after init scripts call sysctl for the values in /etc/sysctl.conf >> >> For modules to use the values stored in the file /etc/sysctl.conf, sysctl >> kernel code can keep record of 'limited' values, for sysctl entries which >> haven't been registered yet. During registration, sysctl code can check >> against the stored values and call the appropriate strategy and >> proc_handler routines if a match is found. >> >> Attached patch does just that. This patch is NOT tested and is just to get >> opinions, if something like this is a right way of addressing this >> problem. > > Do you anticipate any users that you could list? It seems like a more > appropriate approach would be to allow some kind of user-space hook or event > notification to run upon module insertion, which could then apply the > appropriate sysctl. 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". 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. Thanks, Chase - 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/