linux-kernel - Re: [PATCH] SCSI: fix isa/pcmcia compile problem

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 19 Jan 2008 08:28:42 +0900
From:	Tejun Heo <htejun@...il.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	fischer@...bit.de, Andy Whitcroft <apw@...dowen.org>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Samuel Ortiz <samuel@...tiz.org>
Subject: Re: [PATCH] SCSI: fix isa/pcmcia compile problem

Tejun Heo wrote:
> James Bottomley wrote:
>> On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
>>> aha152x.c and fdomain are built twice - once for the isa driver and
>>> once for the PCMCIA one.  Through #ifdefs, the compiled codes are
>>> slightly different; thus, global symbols need to be given different
>>> names depending on which flavor is being built.  This patch adds
>>> GLOBAL() macro to aha152x.h and fdomain.h which change the symbol
>>> depending on PCMCIA.
>>>
>>> This bug has always existed but has been masked by the fact the
>>> drivers/scsi/pcmcia used subdir-(y|m) instead of obj-(y|m) which made
>>> drivers/scsi/pcmcia/built_in.o not linked into the kernel and thus
>>> avoided the duplicate symbols during compilation.
>>>
>>> Signed-off-by: Tejun Heo <htejun@...il.com>
>>> ---
>>> Ah... missed that one.  Here's the updated version.
>> Actually, isn't the better fix just to return to the original behaviour?
>>
>> As you pointed out, using the subdir instead of obj meant that although
>> the modules were built, the drivers were never linked into the main
>> kernel.  According to the records, this has been the default forever, so
>> there can be no-one anywhere relying on these drivers being built in.
>> Actually, as old style pcmcia drivers, I'm not sure there's much value
>> building them into the kernel anyway.
>>
>> So just modify scsi/pcmcia/Kconfig to make them all depend on m.
> 
> Yeap, there is no problem if you don't allow them to be linked into the
> kernel.  If that's how you want it, please go ahead.
> 
> I personally think it's a bit odd to disallow building into kernel
> because of the peculiarity of the implementation (including c files and
> compiling them slightly differently) and also no one reporting doesn't
> necessarily mean no one has attempted it and failed.

Actually what's better would be to make all symbols static and include
the c file directly into the stub file.  How about that?

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