Re: [PATCH 11/12] pcmcia/net_pcmcia: all net_pcmcia modules dependon PCMCIA

[Randy Dunlap]

Satyam Sharma wrote:
> Hi Randy,
>
> On 6/21/07, Randy Dunlap <randy.dunlap@xxxxxxxxxx> 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. ]

I did test it.  If PCMCIA=m, with my patch, the NET_PCMCIA drivers
cannot be configured as built-in.

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


--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/