Satyam Sharma wrote:
Hi Randy,
On 6/21/07, Randy Dunlap <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
