On Sat, Jul 21, 2007 at 04:36:03PM -0600, Eric W. Biederman wrote: > Alexey Dobriyan <[EMAIL PROTECTED]> writes: > > That's separate patch but CTL_UNNUMBERED must die, because it's totally > > unneeded. If you don't want sysctl(2) interface just SKIP ->ctl_name > > initialization and save one line for something useful.
[9p and .ctl_name] > Now to the issue of using CTL_UNNUMBERED versus knowing that the magic > value is zero and we can just leave it uninitialized. I don't much > care but given how often people who are not actively watching this > mess up I tend to prefer the explicit value. mmm, from my own experience the quickest way to add sysctl to kernel is to _copy_ from other place and tweak variable name and string itself. I'm sure that's what evebody is doing. And once you're copy-pasting, existence of CTL_UNNUMBERED or absence of it doesn't matter. Propagating of CTL_UNNUMBERED or empty .ctl_name depends entirely on the place from where you're copy-pasting. And since it doesn't matter, we'd better save one line :) > It is a practical > question of how do we get the word out that we should not expand the > binary interface anymore. Article on LWN, scary comment near struct ctl_table::ctl_name, tree-wide removal .ctl_name initializers, periodic grepping of -mm and -rc diffs. I promise to grep next -mm patch and submit CTL_UNNUMBERED removal :) > The only really practical way I can see us doing better then we are > today is to have a separate tree that maps binary numbers into ascii > strings and so we remove the ctl_name field entirely from ctl_table. Not sure how to do this cleanly and without flag-day. And it's additional code. > That way people attempting to assign binary numbers using old > conventions will have code that doesn't even compile, and the > developers themselves are more likely to spot the problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/