From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH 0/59] Cleanup sysctl Date: Tue, 16 Jan 2007 11:54:09 -0700 Message-ID: References: <45AD02FF.605@zytor.com> <45AD1AD7.7030804@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Morton , linux-kernel@vger.kernel.org, Linux Containers , Tony Luck , netdev@vger.kernel.org Return-path: Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:47729 "EHLO ebiederm.dsl.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750887AbXAPSyf (ORCPT ); Tue, 16 Jan 2007 13:54:35 -0500 To: "H. Peter Anvin" In-Reply-To: <45AD1AD7.7030804@zytor.com> (H. Peter Anvin's message of "Tue, 16 Jan 2007 10:35:03 -0800") Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org "H. Peter Anvin" writes: > Eric W. Biederman wrote: >> >>> I think it would be fair to say that if they're not in > they're >>> not architectural, but that doesn't resolve the counterpositive (are there >>> sysctls in which aren't architectural? From the looks of > it, I >>> would say yes.) Non-architectural sysctl numbers should not be exported to >>> userspace, and should eventually be rejected by sys_sysctl. >> >> This last bit doesn't make much sense. I believe you are saying all sysctl >> numbers should be per architecture. >> > > With "architectural" I mean "guaranteed to be stable" (as opposed to > "incidental"). Sorry for the confusion. Ok. Then largely we are in agreement. To implement that the rule is simple. If it isn't CTL_UNNUMBERED and the number is in Linus's tree, it is our responsibility to never change the meaning of that number. If a new sysctl entry is introduced it should be CTL_UNNUMBERED until it reaches Linus's tree to avoid conflicts. There is simply no point in having any kind of support for numbers whose meanings can change. Which is why I removed the few cases of binary number duplication I found. Eric