[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimBkMJN3h2iYGckUnqJhkkYNcTOoxm9z4qj-9ow@mail.gmail.com>
Date: Tue, 18 May 2010 08:42:02 -0500
From: kevin granade <kevin.granade@...il.com>
To: Vegard Nossum <vegard.nossum@...il.com>
Cc: Jon Smirl <jonsmirl@...il.com>, 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 Tue, May 18, 2010 at 7:54 AM, Vegard Nossum <vegard.nossum@...il.com> wrote:
> 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.
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@...r.kernel.org
> 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@...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