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]

Message-Id: <1200699173.3111.77.camel@localhost.localdomain>
Date:	Fri, 18 Jan 2008 17:32:53 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Tejun Heo <htejun@...il.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


On Sat, 2008-01-19 at 08:27 +0900, 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.

Heh ... I'll make you a deal.  Find just one user of one of these
drivers who can make use of them built in, and I'll apply the patch.  

I'm just a bit reluctant to touch these drivers, since they're all
incredibly ancient.  We don't have good luck with simple transformation
patches on the older drivers ... and it seems to take months before
anyone notices there's a problem.

James


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