On Sun, Jan 06, 2008 at 02:13:09PM +0100, Stefan Richter wrote:
quoted text
> Adrian Bunk wrote:
> > On Sun, Jan 06, 2008 at 01:18:48PM +0100, Stefan Richter wrote:
> >> I'm afraid this can't be put into practice.  (User says which hardware
> >> and protocols he needs to be supported, scripts magically assemble a
> >> suitable configuration.)
> > 
> > Distribution installers and live CDs like Knoppix even manage to 
> > magically assemble a suitable configuration (e.g. autodetecting which 
> > modules they should load) without asking the user any questions.
> 
> Module autoloading is quite different.

Both are "hardware -> required kernel support" mappings.

I know that people don't like this idea since the CML2 discussions, but 
there even don't seem to be any big problems if anyone wants to put all 
the pieces together and assemble a suitable .config only based on the 
autodetection tools of some distribution and without asking the user 
any questions.

quoted text
> > The information the user has to give when configuring his kernel is 
> > whether he wants to connects USB disks - whether or not the 
> > implementation of the kernel driver uses the in-kernel SCSI layer we can 
> > easily handle automatically without bothering the user.
> > 
> >> I think
> >>   - sensibly modularize our software,
> >>   - tell the user which software components there are,
> >>   - what they are for,
> >>   - how they depend on each other,
> >>   - make it easy enough for the user to navigate in the dependency
> >>     graph,
> >>   - provide fundamental safeguards and checks for a proper software
> >>     configuration
> >> is the best we can do.
> > 
> > It sounds strange that what you call the "the best we can do" would be 
> > much worse than what we are currently doing...
> > 
> > The current status quo is that a user e.g. only has to know that his 
> > ethernet controller is a "Broadcom 440x/47xx", the fact that a Sonics 
> > Silicon Backplane bus is used on the card is handled automatically by 
> > kconfig.
> 
> if NET_ETHERNET
> ...
> config B44
> 	tristate "Broadcom 440x/47xx ethernet support"
> 	depends on SSB_POSSIBLE
> 	select SSB
> 	select MII
> ...
> endif # NET_ETHERNET
> 
> There is a B44 option.  The prompt string (in other cases the help text)
> tells what it is for.  Furthermore, four dependencies are encoded; one
> in the direct form, one by if/endif, two in reverse form.  There are no
> further hints how to satisfy SSB_POSSIBLE, NET_ETHERNET, SSB, MII.  The
> kconfig system is told to enable SSB and MII no matter what, as long as
> SSB_POSSIBLE, NET_ETHERNET, and B44 are != n.
> 
> This /is/ what we are currently doing, not "worse than what we are
> currently doing".  We
>   - sensibly modularize our software,
>   - tell the user which software components there are,
>   - what they are for,
>   - how they depend on each other,
>   - make it easy enough for the user to navigate in the dependency
>     graph,
>   - provide fundamental safeguards and checks for a proper software
>     configuration.  (Well, we actually walk on thin ice whenever we
>     use the 'select' keyword.)
>...

You miss the fundamental point:

The vast majority of kconfig users are _not_ kernel hackers, and they 
neither know nor want to know anything about kernel internals - they 
just want to build a kernel suitable for their system.

You want to make an UI easier to use for the developers but harder to 
use for the users, and that's a bad deal.

quoted text
> 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

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/