lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 04 Nov 2006 03:35:00 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andrew Morton <akpm@...l.org>
Cc:	Christoph Lameter <clameter@....com>, linux-kernel@...r.kernel.org
Subject: CTL_UNNUMBERED and killing sys_sysctl

Andrew Morton <akpm@...l.org> writes:

> That has several typos and grammatical mistakes.
>
>> +	VM_MIN_INTERLEAVE=39,	/* Limit for interleave */
>
> I think we recently decided to set all new sysctl number to CTL_UNNUMBERED.
>  Eric, can you remind us of the thinkin there please?

Sure.  Sorry for the delay you buried the question well.

The basic thinking goes as follows.  To properly allocate the
numbers for the binary sysctl interface requires a lot of discipline that
we have proven that we don't always have.  Essentially no one uses
the binary sysctl interface anyway.  Therefore CTL_UNNUMBERED was
introduced so we don't need to allocate a binary sysctl number
to add a sysctl to the /proc/sys, interface.

This avoids approach patch decay before the patch is merged upstream.

So in general if you really need a new binary sysctl number the approach
should be first get your patch merged into Linus's tree and then get
an additional 3 line patch merged into Linus's tree to get your number.

I probably need to wake the conversation up again to see if we can make
the final determinate if we want to drop the binary sysctl interface
after having a long grace period, or simply commit to maintain it.  Linus's
tree still has the binary interface slated for removal in January 2007,
that was only appropriate when we believed there were no users in user space
that cared.

The big maintenance problem has been the bit rot of patches where
people allocate the next number and their patches take a long time to
get into Linus's tree.  So by the time they are merged the patches
conflict over which number they get, and by that time the code has
shipped with a binary interface in a distro kernel.

CTL_UNNUMBERED by freeing us from allocating the binary interface
and just using the file based one gives us a mechanism to solve that
maintenance problem.  I have not heard of a conflict of file names
under /proc/sys.

Andrew can we get the CTL_UNNUMBERED patches pushed up to Linus?

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists