[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20121212.222239.1677083852440112819.davem@davemloft.net>
Date: Wed, 12 Dec 2012 22:22:39 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: torvalds@...ux-foundation.org
Cc: akpm@...ux-foundation.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, nhorman@...driver.com,
vyasevich@...il.com
Subject: Re: [GIT] Networking
From: Linus Torvalds <torvalds@...ux-foundation.org>
Date: Wed, 12 Dec 2012 18:37:08 -0800
> On Wed, Dec 12, 2012 at 6:27 PM, David Miller <davem@...emloft.net> wrote:
>>
>> There are two SCTP HMAC cookie algorithms, MD5 and SHA1.
>>
>> What used to happen is that you had to choose one at build
>> time, and then you were stuck with that decision and it was
>> all that you could use.
>>
>> Now, it's selectable at run time.
>>
>> If there's anything you find particularly anti-social about
>> this, I'm sure we can adjust it.
>
> So I'd suggest doing the same thing that the new thermal throttling
> Kconfig does: start off by asking for the default algorithm, then ask
> about the others.
>
> The "choice" part selects the one that is default (so it never gets
> asked about and is obviously compiled in), and the rest default to no
> like we should.
>
> See drivers/thermal/Kconfig for an example of this. I think we do it
> in other places too, but that one happens to be new so I picked it as
> an example.
>
> The rule should be that we *never* default anything to 'yes', unless
> it's old functionality that we always compiled in before too, and now
> it got made conditional. So if you see a "default y" on new options,
> you should basically consider it broken.
>
> We're already bloating too much, we should not encourage people to
> make things more bloated than necessary.
>
> Btw, that Kconfig option has basically no useful help text either.
> What's the point of repeating the question as a "help" message?
>
> If people can't explain why anybody should enable it, it sure as hell
> shouldn't default to 'y'. Maybe it shouldn't exist at all?
Neil and Vlad, please take care of this.
Thanks.
--
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