Re: [ANNOUNCE] GSoC project: Improving kconfig using a SAT solver

[kevin granade]

On Tue, May 18, 2010 at 7:54 AM, Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote:
> On 18 May 2010 14:26, Jon Smirl <jonsmirl@xxxxxxxxx> wrote:
>> On Tue, May 18, 2010 at 2:03 AM,  <david@xxxxxxx> 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.

At least some of what you want is provided by 'make localmodconfig'

-Kevin Granade

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