lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 20 Jun 2007 15:34:37 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Satyam Sharma <satyam.sharma@...il.com>
CC:	Andreas Herrmann <andreas.herrmann3@....com>,
	jengelh@...ux01.gwdg.de, linux-kernel@...r.kernel.org,
	linux-pcmcia@...ts.infradead.org
Subject: Re: [PATCH 11/12] pcmcia/net_pcmcia: all net_pcmcia modules depend
 on PCMCIA

Satyam Sharma wrote:
> Hi Randy,
> 
> On 6/21/07, Randy Dunlap <randy.dunlap@...cle.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 ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ