public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Satyam Sharma <satyam.sharma@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sam Ravnborg <sam@ravnborg.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Roman Zippel <zippel@linux-m68k.org>,
	Kumar Gala <galak@kernel.crashing.org>,
	Simon Horman <horms@verge.net.au>
Subject: Re: RFC: kconfig select warnings bogus?
Date: Sun, 20 May 2007 20:23:07 +0200	[thread overview]
Message-ID: <20070520182306.GR6291@stusta.de> (raw)
In-Reply-To: <46504876.9040802@s5r6.in-berlin.de>

On Sun, May 20, 2007 at 03:09:10PM +0200, Stefan Richter wrote:
>...
> Since you mention "select":  My opinion about the "select" dialect of
> "depends on" is that the UIs should be improved and "select" should be
> removed from the Kconfig language.  What do we "select"?  Typically we
> "select" an option on which /n/ other options depend on but which itself
> does depend on none or few options higher up.  The UIs could be able to
> figure this out for themselves, or if necessary by a hint tacked onto
> library-type options.  That is, instead of
> 
> 	config A
> 		tristate "driver A"
> 		select L
> 
> 	config B
> 		tristate "driver B"
> 		select L
> 
> 	config L
> 		tristate "library L"
> 
> write
> 
> 	config A
> 		tristate "driver A"
> 		depends on L
> 
> 	config B
> 		tristate "driver B"
> 		depends on L
> 
> 	config L
> 		tristate "library L"
> 		hint THIS_IS_A_LIBRARY
> 
> Now let UIs "make oldconfig", "make menuconfig", "make randconfig" deal
> with the hint or ignore the hint --- according to the purpose and
> usability requirements of the respective UI.  The "hint
> THIS_IS_SOMETHING" isn't even necessary in many cases to detect roles of
> options, because their position in the dependency graph is already
> saying something about it.
>...

Example where your proposal wouldn't work well:

config MIPS_ATLAS
        bool "MIPS Atlas board"
        select SYS_SUPPORTS_LITTLE_ENDIAN
        select SYS_SUPPORTS_BIG_ENDIAN

config SYS_SUPPORTS_BIG_ENDIAN
        bool

config CPU_BIG_ENDIAN
        bool "Big endian"
        depends on SYS_SUPPORTS_BIG_ENDIAN


Where's the value of allowing an UI to ignore hints? If an UI would 
ignore all hints on SYS_SUPPORTS_BIG_ENDIAN you would no longer be able 
to configure a kernel on this architecture.

And there's no way for an UI to figure out the direction of the options - 
with "select" the only reasonable direction is fixed for all UIs.

"select" might have room for improvements especially in the area of 
dependencies of select'ed options, but replacing it with overloading
"depends on" plus hints wouldn't be a good solution.

> Stefan Richter

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


  parent reply	other threads:[~2007-05-20 18:23 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-19 15:15 RFC: kconfig select warnings bogus? Sam Ravnborg
2007-05-19 18:09 ` Andrew Morton
2007-05-19 22:17   ` Satyam Sharma
2007-05-19 22:49     ` Satyam Sharma
2007-05-19 23:09       ` Adrian Bunk
2007-05-19 23:17         ` Satyam Sharma
2007-05-19 23:25           ` Adrian Bunk
2007-05-19 23:36             ` Satyam Sharma
2007-05-19 23:41               ` Satyam Sharma
2007-05-19 23:51                 ` Adrian Bunk
2007-05-20  0:02                   ` Satyam Sharma
2007-05-19 23:48               ` Adrian Bunk
2007-05-19 23:55                 ` Satyam Sharma
2007-05-20  0:13                   ` Adrian Bunk
2007-05-20  0:19                     ` Satyam Sharma
2007-05-20  9:52                       ` Trent Piepho
2007-05-20 10:58                         ` Stefan Richter
2007-05-20 11:23                           ` Trent Piepho
2007-05-20 11:44                             ` Stefan Richter
2007-05-20 19:57                               ` Trent Piepho
2007-05-20 20:12                                 ` Stefan Richter
2007-05-20 20:41                                   ` Trent Piepho
2007-05-22 15:13                                     ` Satyam Sharma
2007-05-20 18:30                         ` Adrian Bunk
2007-05-20  0:46       ` Stefan Richter
2007-05-20  0:53         ` Satyam Sharma
2007-05-20  1:04           ` Satyam Sharma
2007-05-20  8:31             ` Stefan Richter
2007-05-20 11:38               ` Satyam Sharma
2007-05-20 11:47                 ` Stefan Richter
2007-05-20 11:57                   ` Satyam Sharma
2007-05-20 13:09                     ` Stefan Richter
2007-05-20 13:50                       ` Satyam Sharma
2007-05-20 14:39                         ` Stefan Richter
2007-05-22 14:53                           ` Satyam Sharma
2007-05-22 17:03                             ` Stefan Richter
2007-05-22 17:13                               ` Satyam Sharma
2007-05-22 17:38                                 ` Stefan Richter
2007-05-22 17:46                                   ` Satyam Sharma
2007-05-22 17:54                                     ` Stefan Richter
2007-05-22 17:59                                       ` Satyam Sharma
2007-05-20 18:23                       ` Adrian Bunk [this message]
2007-05-19 23:05   ` Adrian Bunk
2007-05-19 23:17     ` Satyam Sharma
2007-05-19 23:21       ` Satyam Sharma
2007-05-19 23:29         ` Adrian Bunk
2007-05-19 23:32           ` Satyam Sharma
2007-05-19 23:23       ` Adrian Bunk
2007-05-19 23:22     ` Andrew Morton
2007-05-20  0:02       ` Adrian Bunk
2007-05-20  0:11         ` Satyam Sharma
2007-05-20  9:43         ` Russell King
2007-05-20  9:40       ` Russell King
2007-05-20 10:17         ` Sam Ravnborg
2007-05-20 11:07         ` Geert Uytterhoeven
2007-05-21  0:25 ` Roman Zippel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070520182306.GR6291@stusta.de \
    --to=bunk@stusta.de \
    --cc=akpm@linux-foundation.org \
    --cc=galak@kernel.crashing.org \
    --cc=horms@verge.net.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=satyam.sharma@gmail.com \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox