9 messages, 5 authors, 2007-05-07 · open the first message on its own page
From: Krzysztof Halasa <khc@pm.waw.pl>
Date: 2007-05-07 16:50:13
Roman Zippel [off-list ref] writes:
HDLC doesn't really look like simple library code, what's up with all the HDLC_* options?
Sub-modules. Anyway, what does the patch "screw" exactly? -- Krzysztof Halasa
From: Roman Zippel <hidden>
Date: 2007-05-07 17:07:53
Hi, On Mon, 7 May 2007, Krzysztof Halasa wrote:
Roman Zippel [off-list ref] writes:quoted
HDLC doesn't really look like simple library code, what's up with all the HDLC_* options?Sub-modules.
So it's not simple library code, or is it?
Anyway, what does the patch "screw" exactly?
Normal dependencies, you basically have to manually make sure they are correct (and it seems with your patch they aren't). Again, _please_ (with sugar on top) don't use select unless you have a good reason for it. bye, Roman
From: Satyam Sharma <hidden>
Date: 2007-05-07 18:16:09
On 5/7/07, Roman Zippel [off-list ref] wrote:
Hi, On Mon, 7 May 2007, Krzysztof Halasa wrote:quoted
Roman Zippel [off-list ref] writes:quoted
HDLC doesn't really look like simple library code, what's up with all the HDLC_* options?Sub-modules.So it's not simple library code, or is it?quoted
Anyway, what does the patch "screw" exactly?Normal dependencies, you basically have to manually make sure they are correct (and it seems with your patch they aren't). Again, _please_ (with sugar on top) don't use select unless you have a good reason for it.
Yes, mixing select and depends is a recipe for build disasters. Call
me a rabid fanatic, but I would in fact go as far as to say that this
whole "select" thing in the Kconfig process is one big BUG, and not a
feature. People are lazy by nature and would rather just "select" a
dependency for their config option than burden users with several
"depends".
The following rant doesn't apply only to the select above, but
unfortunately, that's precisely what happens when such stuff is
introduced ... they seem like a good idea to the introducer for his
special / rarest-of-rare case, but then others tend to {ab-,mis-}use
it and the use of such primitives soon proliferates even to cases
where they are clearly inapplicable / avoidable.
From: Jeff Garzik <hidden>
Date: 2007-05-07 20:32:04
Satyam Sharma wrote:
Yes, mixing select and depends is a recipe for build disasters. Call me a rabid fanatic, but I would in fact go as far as to say that this whole "select" thing in the Kconfig process is one big BUG, and not a feature. People are lazy by nature and would rather just "select" a dependency for their config option than burden users with several "depends".
Tough, the kernel community has voted against you. It makes far more sense to include a driver during kernel configuration, and have that driver pull in its libraries via 'select'. The lame alternative requires developers to know which libraries they need BEFORE picking their drivers, which is backwards and requires legwork on the part of the kernel developer. Jeff
From: Randy Dunlap <hidden>
Date: 2007-05-07 20:49:00
On Mon, 07 May 2007 16:31:48 -0400 Jeff Garzik wrote:
Satyam Sharma wrote:quoted
Yes, mixing select and depends is a recipe for build disasters. Call me a rabid fanatic, but I would in fact go as far as to say that this whole "select" thing in the Kconfig process is one big BUG, and not a feature. People are lazy by nature and would rather just "select" a dependency for their config option than burden users with several "depends".Tough, the kernel community has voted against you.
Andrew (usually) implores people not to use "select" and I agree with him.
It makes far more sense to include a driver during kernel configuration, and have that driver pull in its libraries via 'select'. The lame alternative requires developers to know which libraries they need BEFORE picking their drivers, which is backwards and requires legwork on the part of the kernel developer.
Developers? If you had said "users," I might agree, but IMO it's OK (or even Good) for developers to know what libraries their code uses/requires. Yes, that's a good thing. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***
From: Satyam Sharma <hidden>
Date: 2007-05-07 20:49:59
On 5/8/07, Jeff Garzik [off-list ref] wrote:
Satyam Sharma wrote:quoted
Yes, mixing select and depends is a recipe for build disasters. Call me a rabid fanatic, but I would in fact go as far as to say that this whole "select" thing in the Kconfig process is one big BUG, and not a feature. People are lazy by nature and would rather just "select" a dependency for their config option than burden users with several "depends".Tough, the kernel community has voted against you.
Heh ... I guess I appeared a trifle _too_ fanatic there, but I'm not.
That rant against it was actually more about controlling its
{ab-,mis-}use and rampant proliferation (even to cases where it is
inapplicable / avoidable) than removing it altogether. Especially,
when a developer is lazy / wrong and mixes select and depends in the
same dependency chain leading to errors.
It makes far more sense to include a driver during kernel configuration, and have that driver pull in its libraries via 'select'. The lame alternative requires developers to know which libraries they need BEFORE picking their drivers, which is backwards and requires legwork on the part of the kernel developer.
(That bit about a developer _knowing_ which libraries to select manually before selecting a driver is not really true, you can "?" on a config item and get all its "depends" and "select" dependencies anyway -- and it requires more leg work, yes, but then you'll never have build failures either) Still, I don't really disagree w.r.t. "select"ing libraries, as long as we're careful to limit them to _only_ libraries.
From: Roman Zippel <hidden>
Date: 2007-05-07 20:58:14
Hi, On Mon, 7 May 2007, Jeff Garzik wrote:
Tough, the kernel community has voted against you. It makes far more sense to include a driver during kernel configuration, and have that driver pull in its libraries via 'select'. The lame alternative requires developers to know which libraries they need BEFORE picking their drivers, which is backwards and requires legwork on the part of the kernel developer.
Jeff, there was never anything to "vote" about! There is no autoconfiguration, kernel configuration isn't ready for Aunt Tilly and select is no substitute for it... bye, Roman
From: Satyam Sharma <hidden>
Date: 2007-05-07 22:39:57
On 5/8/07, Randy Dunlap [off-list ref] wrote:
On Mon, 07 May 2007 16:31:48 -0400 Jeff Garzik wrote:quoted
Satyam Sharma wrote:quoted
Yes, mixing select and depends is a recipe for build disasters. Call me a rabid fanatic, but I would in fact go as far as to say that this whole "select" thing in the Kconfig process is one big BUG, and not a feature. People are lazy by nature and would rather just "select" a dependency for their config option than burden users with several "depends".Tough, the kernel community has voted against you.Andrew (usually) implores people not to use "select" and I agree with him.quoted
It makes far more sense to include a driver during kernel configuration, and have that driver pull in its libraries via 'select'. The lame alternative requires developers to know which libraries they need BEFORE picking their drivers, which is backwards and requires legwork on the part of the kernel developer.Developers? If you had said "users," I might agree, but IMO it's OK (or even Good) for developers to know what libraries their code uses/requires. Yes, that's a good thing.
You're absolutely right, but to give Jeff the benefit of the doubt I'm sure he _meant_ "users" there although he said "developers". Stating the obvious, the developer _has_ to know what stuff his code uses anyway, otherwise what does he "select"s or "depends" his config option on. As for users, we _can_ avoid pitfalls by building a complete dependency tree and just selecting _everything_ that we require for a particular config option to be selected, but some users could conceivably prefer only being _told_ about what else they need to successfully pick a config option (than everything just getting in behind their backs). Actually (correct me if I'm wrong), this is not presently possible: an option is not visible unless dependencies are already picked. Just a suggestion, though.
From: Randy Dunlap <hidden>
Date: 2007-05-07 22:49:48
Satyam Sharma wrote:
On 5/8/07, Randy Dunlap [off-list ref] wrote:quoted
On Mon, 07 May 2007 16:31:48 -0400 Jeff Garzik wrote:quoted
Satyam Sharma wrote:quoted
Yes, mixing select and depends is a recipe for build disasters. Call me a rabid fanatic, but I would in fact go as far as to say that this whole "select" thing in the Kconfig process is one big BUG, and not a feature. People are lazy by nature and would rather just "select" a dependency for their config option than burden users with several "depends".Tough, the kernel community has voted against you.Andrew (usually) implores people not to use "select" and I agree with him.quoted
It makes far more sense to include a driver during kernelconfiguration,quoted
and have that driver pull in its libraries via 'select'. The lame alternative requires developers to know which libraries they needBEFOREquoted
picking their drivers, which is backwards and requires legwork on the part of the kernel developer.Developers? If you had said "users," I might agree, but IMO it's OK (or even Good) for developers to know what libraries their code uses/requires. Yes, that's a good thing.You're absolutely right, but to give Jeff the benefit of the doubt I'm sure he _meant_ "users" there although he said "developers". Stating the obvious, the developer _has_ to know what stuff his code uses anyway, otherwise what does he "select"s or "depends" his config option on. As for users, we _can_ avoid pitfalls by building a complete dependency tree and just selecting _everything_ that we require for a particular config option to be selected, but some users could conceivably prefer only being _told_ about what else they need to successfully pick a config option (than everything just getting in behind their backs). Actually (correct me if I'm wrong), this is not presently possible: an option is not visible unless dependencies are already picked. Just a suggestion, though.
That's correct for menuconfig. For xconfig, there are GUI options to Show Name Show Range Show Data Show All Options Show Debug Info I often have all of them enabled. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***