Options depending on STANDALONE

[Adrian Bunk]

On Thu, Aug 03, 2006 at 03:56:17PM -0400, Dave Jones wrote:
> On Thu, Aug 03, 2006 at 12:36:00PM -0700, Greg Kroah-Hartman wrote:
> 
>  > > That is good to know.  But there is a kernel option which doesn't make 
>  > > much sense in that case:
>  > > 
>  > > [*] Select only drivers that don't need compile-time external firmware
>  > 
>  > No, that is very different.  That option is present if you don't want to
>  > build some firmware images from the source that is present in the kernel
>  > tree, and instead, use the pre-built stuff that is also present in the
>  > kernel tree.
> 
> You're describing PREVENT_FIRMWARE_BUILD.  The text Zach quoted is from
> STANDALONE, which is something else completely.  That allows us to not
> build drivers that pull in things from /etc and the like during compile.
> (Whoever thought that was a good idea?)

We should also look at what drivers do depend on STANDALONE:
- some OSS drivers
- one DVB driver option (DVB_AV7110_FIRMWARE)
- ACPI_CUSTOM_DSDT

The OSS drivers are more or less RIP, so let's ignore them.

Is DVB_AV7110_FIRMWARE really still required?
ALL other drivers work without such an option.

ACPI_CUSTOM_DSDT seems to be the most interesting case.
It's anyway not usable for distribution kernels, and AFAIR the ACPI 
people prefer to get the kernel working with all original DSDTs
(which usually work with at least one other OS) than letting the people 
workaround the problem by using a custom DSDT.

It might therefore be possile simply getting rid of CONFIG_STANDALONE?

> 		Dave

cu
Adrian

-- 

    Gentoo kernels are 42 times more popular than SUSE kernels among
    KLive users  (a service by SUSE contractor Andrea Arcangeli that
    gathers data about kernels from many users worldwide).

       There are three kinds of lies: Lies, Damn Lies, and Statistics.
                                                    Benjamin Disraeli

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