Date:	Tue, 18 May 2010 14:54:36 +0200
From:	Vegard Nossum <vegard.nossum@...il.com>
To:	Jon Smirl <jonsmirl@...il.com>
Cc:	david@...g.hm,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	linux-kbuild@...r.kernel.org, Bart Massey <bart@...pdx.edu>,
	Michal Marek <mmarek@...e.cz>,
	Greg Kroah-Hartman <greg@...ah.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [ANNOUNCE] GSoC project: Improving kconfig using a SAT solver

On 18 May 2010 14:26, Jon Smirl <jonsmirl@...il.com> wrote:
> On Tue, May 18, 2010 at 2:03 AM,  <david@...g.hm> wrote:
>> There are two modes people can be in when configuring a kernel.
>>
>> 1. I want to configure a kernel to support my hardware, enable anything else
>> needed to make it work.
>>
>> 2. I really care about having a small kernel, don't enable anything I have
>> disabled (but help me figure out why something I want isn't available)
>>
>> I don't think that hiding hardware from the user is ever the best thing to
>> do. for approach #1 you obviously don't want to hide anything, but even for
>> approach #2, someone may not realize that by disabling one option they are
>> making it impossible to support something, and as someone who spent a bunch
>> of time hunting through config to find options that I ended up finding were
>> not available without enabling something else, I much prefer to see the
>> option, but see it disabled rather than not being sure if it should be
>> there, or somewhere else in the config.
>
> I have to agree with this. An example is audio drivers that disappear
> because something like SPI is turned off. Sometimes I have to read the
> Kconfig files to figure out what subsystems I need enabled in order to
> make the driver appear as a choice.
>
> Another way this could work...
> Enable the platform
> this causes all subsystems on the platform (usb, spi, pci, etc) to be
> soft enabled
> user selects device drivers or hard enables the subsystem
> on save, if the subsystem wasn't hard enabled for some reason or
> dependency, disable it.
>
> ---------------
>
> I'd also find it useful if Kconfig had an option that analyzed the
> system it is running on and then generated the minimal set of drivers
> needed to support it. Assume that the system is running something like
> the Ubuntu kernel with every driver enabled. Then figure out the
> minimal build footprint for a custom kernel to support the same
> hardware.  I do this by hand, but a button for doing it would be a lot
> easier.

Consider this a response to both of the above e-mails. Just to clear
any confusion, a consequence of using SAT for kconfig is that you can
now say for example only the following: "I want drivers A, B, and C. I
don't care if that means I can't use FOO and I don't care if that
means that I have to use BAR, just give me A, B, and C."

I suppose another way to see it is that configuring the kernel using
the current menuconfig is a top-down process, since you have to select
USB before you can select any driver that depends on USB. Using SAT
for kconfig puts this on its head, and the configuration process
becomes bottom-up; you say only what you want to have (or not have),
and the system figures out the rest. If you choose a driver that
requires USB (and you haven't said that you also don't want USB
support, which would be impossible), then USB _will_ be enabled
automatically.

For the record, I think that there are already scripts that take a
running system and builds a config for that.


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

Powered by blists - more mailing lists