[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D2EEEAA.7040200@suse.cz>
Date: Thu, 13 Jan 2011 13:23:06 +0100
From: Michal Marek <mmarek@...e.cz>
To: Len Brown <lenb@...nel.org>
Cc: "Rafael J. Wysocki" <rjw@...k.pl>,
Andrew Morton <akpm@...ux-foundation.org>,
Randy Dunlap <randy.dunlap@...cle.com>,
linux-acpi@...r.kernel.org,
Stephen Rothwell <sfr@...b.auug.org.au>,
Zhang Rui <rui.zhang@...el.com>, linux-next@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>, Zimn@...per.es,
Arnaud Lacombe <lacombar@...il.com>,
Vegard Nossum <vegard.nossum@...il.com>
Subject: Re: on builds/randconfigs
On 12.1.2011 22:58, Len Brown wrote:
>>> These unusable config combinations should be prevented via Kconfig.
>>> That prevents users from selecting them, which otherwise adds to
>>> our workload and to theirs. It also prevents false-positives
>>> during our useful randconfig testing.
>>
>> But it is kind of difficult to achieve IMhO. For example, there are options
>> that are only SELECTed if something else is set, but randconfig doesn't seem
>> to care.
>
> Kconfig select needs to be fixed so that it is not possible to
> select something if that something's dependencies are not met.
Right now, it issues a warning in such case. I think changing it to a
fatal error would be too premature, not long ago there were a couple of
annoying false positives.
But from the rest of the thread, I conclude that you actually meant "not
possible to select something if that something's dependencies CANNOT be
met", i.e. automatically select dependencies if that is possible. That
was actually one of the goals of Vegard Nossum's GSoC poject last year,
but I haven't heard of any outcome yet. Vegard, is there something we
could use, be it code or mistakes we could learn from?
Thanks,
Michal
--
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