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

[Randy Dunlap <randy.dunlap@oracle.com>]

Satyam Sharma wrote:
> 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. ]

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