From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH] IPVS: Fix sysctl warnings about missing strategy Date: Wed, 14 Nov 2007 18:25:00 -0700 Message-ID: References: <200711131129.58868.borntraeger@de.ibm.com> <20071113.024500.155458534.davem@davemloft.net> <20071114021131.GB2523@verge.net.au> <20071115011431.GA8325@verge.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Julian Anastasov , David Miller , borntraeger@de.ibm.com, netdev@vger.kernel.org, ebiederm@xmission.com, wensong@linux-vs.org To: Simon Horman Return-path: Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:56778 "EHLO ebiederm.dsl.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755229AbXKOBZ6 (ORCPT ); Wed, 14 Nov 2007 20:25:58 -0500 In-Reply-To: <20071115011431.GA8325@verge.net.au> (Simon Horman's message of "Wed, 14 Nov 2007 17:14:36 -0800") Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Simon Horman writes: > On Thu, Nov 15, 2007 at 02:38:32AM +0200, Julian Anastasov wrote: > > Hi Julian, > >> On Tue, 13 Nov 2007, Simon Horman wrote: > > [snip] > >> > As for the commented out entries. They are supposed to be exposed by >> > some other means - I believe the thinking was to comply with the don't >> > expose stuff in proc any more idea. Where is the best place to expose >> > this kind of stuff? >> >> I assume /proc/sys is still valid place, only sysctl interface >> is scheduled for removal. > > I'm happy to add them there, so long as that is a good place. For simple integer values /proc/sys (ala the ascii sysctl interface) seems as good as any to me. The binary interface is problematic because it doesn't get used and so we don't show proper discipline with binary integers leading to silent ABI changes, and the actual implementation of the handler routines get out of sync with the proc side giving us different meanings. >> So, as long as these entries are not >> accessible from sysctl it is safe to run without strategy handler but if >> values can be changed then we will need strategy handler to >> properly call update_defense_level() as done in proc_do_defense_mode() >> as proc_handler. There could be side effects if new mode is not applied. > > I'm not sure what you are getting at there. I did write a stratergy > for update_defense_level(), but I didn't post it, as I thought that > it would not be needed if CTL_UNNUMBERED is used. Strategy routines are never called if CTL_UNNUMBERED is used. So you should be safe just killing the ctl_name field or setting it explicitly to CTL_UNNUMBERED. Eric