Re: build issue #503 for v2.6.26-rc2-433-gf26a398 : undefined reference to `request_firmware'

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sat, 2008-05-17 at 17:17 +0300, Adrian Bunk wrote:
> On Sat, May 17, 2008 at 11:04:31AM +0100, James Bottomley wrote:
> > On Fri, 2008-05-16 at 19:06 +0200, Toralf Förster wrote:
> > > Hello,
> > > 
> > > the build (.config attached) failed, make ends with :
> > > ...
> > >   UPD     include/linux/compile.h
> > >   CC      init/version.o
> > >   LD      init/built-in.o
> > >   LD      vmlinux
> > > drivers/built-in.o: In function `sas_request_addr':
> > > (.text+0x33bab): undefined reference to `request_firmware'
> > > drivers/built-in.o: In function `sas_request_addr':
> > > (.text+0x33c3f): undefined reference to `release_firmware'
> > > make: *** [vmlinux] Error 1
> > 
> > There's a slight fault in the stub logic.  It fails for FW_LOADER=m and
> > the user =y.
> > 
> > This should fix it.
> 
> An interesting question is whether we actually want to have the stub at 
> all - the compile errors catched cases where someone forgot to select 
> FW_LOADER at compile time instead of turning them into possible runtime 
> problems as will happen after your patch.

Well, the original intent of the stubs was to have the loader nop if it
wasn't available.  There was simply one case forgotten (the fact that a
modular loader isn't usable from built in components).

> Are there any serious use cases where SCSI_SAS_LIBSAS is used in very 
> space limited environments and without any other drivers that select 
> FW_LOADER in the kernel?

Probably in the future, certainly on embedded OSs used for storage
devices.  Given the convergence of SAS/SATA chips, it's possible for
other handhelds, but I'm not convinced of that.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html