linux-kernel - Re: on builds/randconfigs (was: [PATCH -next] thermal: depends on NET)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 12 Jan 2011 13:35:10 -0500 (EST)
From:	Len Brown <lenb@...nel.org>
To:	Randy Dunlap <randy.dunlap@...cle.com>
Cc:	linux-acpi@...r.kernel.org,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	akpm <akpm@...ux-foundation.org>,
	Zhang Rui <rui.zhang@...el.com>, linux-next@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	Zimny Lech <napohybelskurwysynom2010@...il.com>
Subject: Re: on builds/randconfigs (was: [PATCH -next] thermal: depends on NET)

> > While I agree that randconfig build testing
> > is theoretically useful, in recent memory
> > its results do not seem particularly relevant
> > to useful configs.
> 
> Who defines useful?

Simple.

Configs that will be used are useful.

Phantom configs that will NEVER be used are NOT useful.

Phantom configs are HARMFUL, as they squander
finite testing and maintainer resources
that should be applied to code that is actually used.

Rather than celebrating our theoretical flexibility
with every new config option, we should recoil at the
fact that each one may up to double the number of
configs that need to be tested and supported.

When I'm answering your nagging e-mail about a build failure
in a phantom config that nobody would even conceive of using,
I'm not using that time to fix somebody's real problem
on a real machine.

I'd rather see you spend your time making select work
to delete an entire category of Kconfig failures,
or simply adding dependencies making phantom configs impossible.

eg. Look in drivers/acpi/Kconfig:

menuconfig ACPI
        bool "ACPI (Advanced Configuration and Power Interface) Support"
        depends on !IA64_HP_SIM
        depends on IA64 || X86
        depends on PCI
        depends on PM
        select PNP

Does all of ACPI technically depend on PCI?
Does all of ACPI technically depend on PM support?
Does all of ACPI technically depend on configuration and PNP?

Theoretically, no.

Do I care about the phantom configs that would be possible
if these false dependencies were not in place.  No,
not until somebody invents such a system,
and may be not even then.

Is there a user out there on LKML who can dream up
a use for one of these phantom configs and claim that
his life will end if he'd prevented from building it?
Sure.  Does he suffer from a total lack of perspective?
Yes.

-Len Brown, Intel Open Source Technology Center
--
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/