Andreas Herrmann wrote:
On Tue, Jun 19, 2007 at 08:51:58PM -0700, Randy Dunlap wrote:
On Tue, 19 Jun 2007 20:49:34 -0700 Randy Dunlap wrote:
On Tue, 19 Jun 2007 23:38:02 -0400 Len Brown wrote:
On Tuesday 19 June 2007 18:50, Andreas Herrmann wrote:
Avoid compile warning if !ACPI_BLACKLIST_YEAR
CC drivers/acpi/blacklist.o
drivers/acpi/blacklist.c:76:5: warning: "CONFIG_ACPI_BLACKLIST_YEAR" is not defined
How were you able to produce a .config with CONFIG_ACPI_BLACKLIST_YEAR not defined?
Can you send it to me?
'make randconfig' does that kind of thing. It doesn't enforce/follow
"select" clauses.
I should have also said: randconfig is good for detecting some
missing conditions/configs or missing header files, but if you find one
that is just plain Invalid (like some of these), just say so
and do whatever you want with the patch (IMHO of course).
I think of randconfig as
"make config with random answers to all questions"
(Or did I miss something?)
This means that randconfig does not give totally random
configurations. The same restrictions apply for config,
randconfig and menuconfig. If not we might consider fixing
scripts/kconfig/conf.c and friends.
The last time that I looked at the config code, randconfig generates
a random value for config symbols, taking "depends on" into account,
but it does not take "select" into account. Or put another way,
it does not follow "select" chains.
and IIRC, running "make oldconfig" after that still won't enforce
the "select"s. This is a long-running problem and one of the problems
with using "select" at all.
So in general a "randconfig" configurations can be generated by a user
as well. He just has to give the same answers during "make config"
as randconfig did.
I started this randconfig thing yesterday and up to now I have looked
at 16 (out of >66) configs which lead to kernel build errors with
the current git tree.
Of course I have seen duplicates of the problems reported.
But there were just 3 (all equal) bogus configurations. There randconfig
did not provide a proper file name for CONFIG_ACPI_CUSTOM_DSDT_FILE.
This is the only case for which I would use the term "user error" or
"bogus randconfig".
IMHO if certain configurations are invalid we should use kconfig-language
to prevent them.
Ah and wrt to the above compile warning. Normally I would have ignored
it - but I looked at acpi code and its Kconfig anyway.
And It's easy to avoid such a warning to keep the terminal clear
for more interesting compile messages ;-)
Regards,
Andreas
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
