From: Felipe Contreras on
On Mon, May 17, 2010 at 3:02 PM, Vegard Nossum <vegard.nossum(a)gmail.com> wrote:
> Hi,
>
> I just wanted to say that I've been accepted into this year's Google
> Summer of Code program and will spend this summer working on improving
> the kconfig system in a very particular direction: I want to integrate
> a proper boolean constraint satisfiability solver into the
> configuration editors (menuconfig, etc.) in order to allow
> partial/incomplete configuration specifications. In short, this means
> that the user can choose to not specify a particular value for some
> config options, but let the system deduce their values. This will
> hopefully improve usability and also solve the select problem once and
> for all.
>
> A slightly shortened version of the project proposal that was accepted
> can be found here:
>
> http://userweb.kernel.org/~vegard/gsoc2010/proposal-short.html
>
> In case anybody would like to track my progress throughout the summer,
> I have set up my public project repositories at:
>
> http://github.com/vegard/dpll
> http://github.com/vegard/linux-2.6-kconfig-sat
>
> I am also planning to post some updates to LKML as milestones are
> completed.  (Please let me know if you would like to be added to or
> removed from the Cc list.) The official end date is August 16, by
> which time I hope to have submitted my work for mainline inclusion.
>
> Feedback is appreciated -- I am also prepared to respond to
> constructive criticism.
>
> Lastly, I would like to thank Google for sponsoring me, and to thank
> Portland State University and my mentor Bart Massey for believing in
> this idea and project.

Very nice! I thought on this idea too.

Does this means that if you have a pristine kernel, and you do 'make
menuconfig' and don't change anything, the .config file will be empty?
And then, anything that you change will be in the .config file?

On another case I do 'make ARCH=arm omap3_beagle_defconfig' then my
..config file will point to that particular defconfig, and I can add
only the changes that I want. Also, omap3_beagle_defconfig probably
points omap3_defconfig and only makes certain changes.

If so, that would be awesome :)

--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Vegard Nossum on
On 19 May 2010 13:05, Felipe Contreras <felipe.contreras(a)gmail.com> wrote:
> On Mon, May 17, 2010 at 3:02 PM, Vegard Nossum <vegard.nossum(a)gmail.com> wrote:
>> Hi,
>>
>> I just wanted to say that I've been accepted into this year's Google
>> Summer of Code program and will spend this summer working on improving
>> the kconfig system in a very particular direction: I want to integrate
>> a proper boolean constraint satisfiability solver into the
>> configuration editors (menuconfig, etc.) in order to allow
>> partial/incomplete configuration specifications. In short, this means
>> that the user can choose to not specify a particular value for some
>> config options, but let the system deduce their values. This will
>> hopefully improve usability and also solve the select problem once and
>> for all.
>
> Very nice! I thought on this idea too.
>
> Does this means that if you have a pristine kernel, and you do 'make
> menuconfig' and don't change anything, the .config file will be empty?
> And then, anything that you change will be in the .config file?
>

Yes and no -- I think the plan is to retain the .config file as it is
(i.e. it specifies more or less every option completely), so that it
remains backwards compatible; bisection, for example, is very
important. But yes, I think there will be a new file, say, .satconfig,
which contains only the specific choices of the user. And this one
would be empty, as you say, with a pristine kernel.

I think, then, that the .config file will be regenerated from the
..satconfig one each time .satconfig changes.

> On another case I do 'make ARCH=arm omap3_beagle_defconfig' then my
> .config file will point to that particular defconfig, and I can add
> only the changes that I want. Also, omap3_beagle_defconfig probably
> points omap3_defconfig and only makes certain changes.
>
> If so, that would be awesome :)

Do you mean essentially a sort of cascade of configurations that
inherit options from a different file? That shouldn't be very hard to
do -- I'll make a note of it for when I get that far! That has the
potential to make the defconfig files a bit shorter and more
manageable (not sure how big a problem that is in practice today,
though).

Thanks,


Vegard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Felipe Contreras on
On Wed, May 19, 2010 at 9:31 PM, Vegard Nossum <vegard.nossum(a)gmail.com> wrote:
> On 19 May 2010 13:05, Felipe Contreras <felipe.contreras(a)gmail.com> wrote:
>> Does this means that if you have a pristine kernel, and you do 'make
>> menuconfig' and don't change anything, the .config file will be empty?
>> And then, anything that you change will be in the .config file?
>
> Yes and no -- I think the plan is to retain the .config file as it is
> (i.e. it specifies more or less every option completely), so that it
> remains backwards compatible; bisection, for example, is very
> important. But yes, I think there will be a new file, say, .satconfig,
> which contains only the specific choices of the user. And this one
> would be empty, as you say, with a pristine kernel.
>
> I think, then, that the .config file will be regenerated from the
> .satconfig one each time .satconfig changes.

I see. As long as people can use .satconfig only if they want, I think
that's great.

>> On another case I do 'make ARCH=arm omap3_beagle_defconfig' then my
>> .config file will point to that particular defconfig, and I can add
>> only the changes that I want. Also, omap3_beagle_defconfig probably
>> points omap3_defconfig and only makes certain changes.
>>
>> If so, that would be awesome :)
>
> Do you mean essentially a sort of cascade of configurations that
> inherit options from a different file? That shouldn't be very hard to
> do -- I'll make a note of it for when I get that far! That has the
> potential to make the defconfig files a bit shorter and more
> manageable (not sure how big a problem that is in practice today,
> though).

Exactly. Well, I don't know if anybody considers that a problem, but
just check arch/arm/configs/*. All of them are much bigger than
needed, and some have not been updated in a long time (even as old as
2.6.11). So if you do make ARCH=arm assabet_defconfig and do a 'diff
..config assabet_defconfig' they would be completely different. This
way it's hard to keep track of the general config changes, and ARM
related changes, and OMAP3 changes, and compare with board-specific
ones.

Cheers.

--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on
Hi!

> >>Even if the problem is different from zypper's, it is also here
> >>possible to get an unsatisfiable instance. You are right that, yes,
> >>the kconfig files on their own should always be satisfiable. But
> >>that's before the user has made any choices at all. An example of an
> >>unsatisfiable instance would be one where the user demands that 1.
> >>some USB driver is enabled, while 2. USB support in general is
> >>disabled.
> >
> >Actually, these are two separate problems. The first is basic
> >consistency within the Kconfig subsytstem (something that select
> >currently damages for us). The second is what to present to the user,
> >which is where the inception of the select problem came from. A user
> >doesn't really want to know that USB device X depends on usb storage,
> >SCSI and a raft of other things ... they just want it to configure a
> >kernel that supports their device. In particular, we don't want to
> >present every possible option to users and then try to work out a
> >solution, we really need guided configuration (which, in some measure,
> >is what we have today: if you don't select general USB, you won't see
> >any USB drivers. Or more importantly, if you select an Adaptec SCSI
> >card, we just enable whichever transport library it needs).
>
> 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)

There are more...

....part of the problem is that kconfig is both user-dependend (what
filesystems do I use) and machine dependend (what does hw need).

Current defconfig system is unfortunately not quite there :-(.

What would be nice for machines like Sharp Zaurus (spitz) would be
defconfig which answered =Y for hardware spitz definitely has (sound),
=N for hardware that can't be connected (anything pci), and something
different (=M?) for hardware that can be connected to it
(pcmcia)... leaving 'user' options like filesystems configured ... up
to the user.
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/