Messages in this thread | | | Date | Thu, 21 Jun 2007 02:55:46 +0530 | From | "Satyam Sharma" <> | Subject | Re: [PATCH 11/12] pcmcia/net_pcmcia: all net_pcmcia modules depend on PCMCIA |
| |
Hi Randy,
On 6/21/07, Randy Dunlap <randy.dunlap@oracle.com> wrote: > On Wed, 20 Jun 2007 00:52:03 +0200 Andreas Herrmann wrote: > > > Fix several build errors with PCMCIA=m && NET_PCMCIA=y: > > > > LD .tmp_vmlinux1 > > drivers/built-in.o: In function `nmclan_release': > > nmclan_cs.c:(.text+0x14026c): undefined reference to `pcmcia_disable_device' > > ... > > drivers/built-in.o: In function `exit_xirc2ps_cs': > > xirc2ps_cs.c:(.exit.text+0x1055): undefined reference to `pcmcia_unregister_driver' > > make: *** [.tmp_vmlinux1] Error 1 > > This is interesting. This is a result of the menuconfig changes, > which made NET_PCMCIA a boolean, and then some tristates depend > on NET_PCMCIA and the boolean -> tristate dependencies aren't > specific enough. > > Your fix is one way to do it. I'd prefer to make > NET_PCMCIA a tristate instead, then let its value trickle down > to the subordinate config symbols.
This is interesting indeed. But would it make much sense to mark a menuconfig item as tristate? I suspect the problem here was simply that these PCMCIA drivers did not explicitly depend on CONFIG_PCMCIA (which they should be, considering they pull in code from that particular subsystem), which Andreas' patch resolves ...
[ Also, when we make NET_PCMCIA tristate here, I suspect it would still be possible to select these drivers as built-in (even though PCMCIA can be modular) which would still give the above errors? I didn't test, so please correct me if I'm wrong. ]
> This probably means that some of the other menuconfig changes > need to be audited for this "feature."
Right. [ I didn't check git history, but it is also possible that these drivers not depend on PCMCIA like they should have before Jan did the menuconfig conversions too. ] But IMHO, the general lesson from this case is that if some driver depends on some other symbol, then we still need to honour that dependency explicitly instead of simply putting the driver inside a "#if <menuconfig_symbol>" and only making the <menuconfig_item> itself depend on the said dependency; otherwise the boolean / tristate problems you mentioned will bite, so an audit would clearly be in order.
Satyam - 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/
| |