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

[Satyam Sharma]

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

> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/