On Tue, Jun 10, 2008 at 09:12:06PM +0300, Adrian Bunk wrote:
quoted text
> On Tue, Jun 10, 2008 at 09:24:50AM -0700, Greg KH wrote:
> > On Tue, Jun 10, 2008 at 07:04:08PM +0300, Adrian Bunk wrote:
> > > James Bottomley recently discovered that we have 
> > > {request,release}_firmware() dummies for the case of the actual 
> > > functions not being available and has a fix for the bug that was 
> > > actually causing build errors for built-in users with 
> > > CONFIG_FW_LOADER=m.
> > > 
> > > But now missing selects on FW_LOADER are no longer visible at 
> > > compile-time at all and can become runtime problems.
> > > 
> > > FW_LOADER is infrastructure with relatively small codesize we can 
> > > safely enable for everyone, and only for people who really need small 
> > > kernels (and can be expected to know what they are doing) it matters 
> > > being able to disable it.
> > > 
> > > This patch therefore always sets FW_LOADER=y and allows users only to 
> > > disable it with EMBEDDED=y.
> > > 
> > > As a bonus, we can then get rid of all "select FW_LOADER" plus the due 
> > > to it required "depends on HOTPLUG" which removes some complexity from 
> > > our Kconfig files.
> > 
> > Well, we can't get rid of that if EMBEDDED is set, right?
> 
> No, if EMBEDDED is set and HOTPLUG is not set you will not be able to
> enable FW_LOADER (the "depends on HOTPLUG" for FW_LOADER has to stay, 
> but all the options that currently select FW_LOADER no longer need the 
> dependency).

Ok, but what about the point that the options that are wanting FW_LOADER
in that situation?  I know EMBEDDED is tough to get right as you can
shoot yourself in the foot very easily, but this seems like we are going
to make it even harder to use properly.

quoted text
> > You sent this as an RFC before, I thought people said to just fix up all
> > of the dependancies with drivers that needed FW_LOADER to be enabled,
> > that would be easier, right?
> 
> As far as I know there were zero answers to my RFC.
> 
> What are you referring to?

Sorry, I thought that was sent to the RFC, I think it was to a thread
even before that.

I don't like this change for the above reason at this point.

thanks,

greg k-h
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/