On Wed, Jul 18, 2007 at 05:18:20PM -0400, Robert P. J. Day wrote: > On Wed, 18 Jul 2007, Adrian Bunk wrote: > > > On Wed, Jul 18, 2007 at 04:51:33PM -0400, Robert P. J. Day wrote: > > > On Wed, 18 Jul 2007, Jeff Garzik wrote: > > > > > > > Randy Dunlap wrote: > > > > > On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote: > > > > > > there's no point adding all that redundant content when it can all > > > > > > be > > > > > > done automatically. > > > > > > > > > > I like it. Are there any kconfig patches to support this plan? > > > > > > > > Speaking specifically to adding 'EXPERIMENTAL', I distinctly > > > > remember at some point in the past the config system was smart > > > > enough to print " (EXPERIMENTAL)" if that entry depended on > > > > CONFIG_EXPERIMENTAL. > > > > > > > > We should head in that direction. > > > > > > there's one point i want to re-iterate. i'd prefer to see > > > EXPERIMENTAL stop being a dependency, as in: > > > > > > depends on SNAFU && FUBAR && EXPERIMENTAL > > > > > > "EXPERIMENTAL" is not a dependency in the true sense of the word > > > -- it is more of an attribute, and i think it would far more sense > > > to see entries like: > > > > > > depends on SNAFU && FUBAR > > > maturity EXPERIMENTAL > > > > Plus some special case in the kconfig code that you can somewhere > > select the maturity levels you want to use (currently it's a normal > > option kconfig doesn't have to know anything about). > > i already described that here: > > http://readlist.com/lists/vger.kernel.org/linux-kernel/66/334172.html > > where the top-level config would look something like: > > [*] Activate maturity attributes > [*] EXPERIMENTAL > [*] DEPRECATED > [*] OBSOLETE > [*] BROKEN
We already made the mistake of offering BROKEN as an option in the past, and the result was that people enabled it instead of reporting that a dependency on BROKEN was wrong. > whereupon you could select any combination of the attributes you want > displayed *beyond the regular ones* during the config process. > > > Remind me, would there be any big advantage after such a change > > besides being able to automatically print " (EXPERIMENTAL)" at the > > end of the prompt? > > defining a new Kconfig attribute means you can process it differently > from regular dependencies. and if it's added as a general feature, it > can be used for other possible attributes beyond just a maturity > level. > > if you leave these maturity levels as regular dependencies, you're > going to have to brute force and manually process them, and why make > it that ugly? I would consider it more ugly to special case this and that in the kconfig code when plain dependencies already offer exactly the same functionality... > rday cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html