[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070811014111.GB22213@stusta.de>
Date: Sat, 11 Aug 2007 03:41:11 +0200
From: Adrian Bunk <bunk@...sta.de>
To: Johannes Berg <johannes@...solutions.net>
Cc: Michael Buesch <mb@...sch.de>,
John Linville <linville@...driver.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH] b44-ssb: Fix the SSB dependency hell
On Sat, Aug 11, 2007 at 02:57:36AM +0200, Johannes Berg wrote:
> On Sat, 2007-08-11 at 02:43 +0200, Adrian Bunk wrote:
>
> > -ENOMENUCONFIGPATCH
>
> Has anybody decided how it could possibly even look like anyhow? It
> should be fixed, but nobody has a plan.
The simplest idea would be that an option select'ing some other option
inherits the dependencies of the latter. That should fix all problems
select currently has.
There are for sure some problems hidden that will show up during
implementation, but since noone is implementing it we'll never know...
> > That's horrible - you shouldn't force the user to manually enable three
> > options.
>
> Well, akpm says: "select is broken. do not ever use it"
select works fine if you understand the pitfalls.
Kconfig is a _user interface_, and making using it easy for the user
is therefore important.
Whenever there's a mistake in a help text or something confusing
users will run into problems with the kernel they compiled.
> > config SSB_PCIHOST_POSSIBLE
> [...]
>
> > depends on SSB_PCIHOST_POSSIBLE
> > select SSB
> > select SSB_PCIHOST
>
> That would, indeed, be possible. But it's ... ugly ... you've now
> effectively pushed the information on what *SSB* depends on into each
> SSB *user* instead of SSB itself...
No, this information is still in drivers/ssb/Kconfig.
This would replace:
config B44
depends on SSB_PCIHOST
with:
config B44
depends on SSB_PCIHOST_POSSIBLE
select SSB_PCIHOST
That's an easily understandable pattern without redundant information
about the required dependencies of SSB_PCIHOST.
> > Is there any extremely good reason why options like SSB or SSB_PCIHOST
> > have to be user visible?
>
> Yes. Embedded systems like the small Linksys routers come with SSB as
> the system bus. No PCI/PCIHOST.
OK.
> > And according to the kconfig help text, we should remove the B44_PCI
> > option and enable the code unconditionally?
> > (Or what was the person writing this help text smoking^Wthinking when
> > writing it?)
>
> Same reason. They have a b44 core there but no pci.
OK, that's understandable.
But the kconfig user currently only gets:
config B44_PCI
bool "Broadcom 440x PCI device support"
...
help
Support for Broadcom 440x PCI devices.
Say Y, unless you know what you are doing.
If you say N here I will _not_ listen to your
bugreports!
An example how to make it better:
config USB_OHCI_HCD_SSB
bool "OHCI support for the Broadcom SSB OHCI core (embedded systems only)"
...
help
Support for the Sonics Silicon Backplane (SSB) attached
Broadcom USB OHCI core.
This device is only present in some embedded devices with
Broadcom based SSB bus.
If unsure, say N.
That's the difference between a silly sounding help text ("I will _not_
listen to your bugreports!") and a help text that gives the kconfig user
all required information ("only present in some embedded devices").
And I'm not yet convinced B44_PCI is really worth bothering the user
with - what about automatically enabling PCI support in the driver if
PCI support is enabled in the kernel?
> johannes
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists