linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4D2DE97C.2000205@oracle.com>
Date:	Wed, 12 Jan 2011 09:48:44 -0800
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Len Brown <lenb@...nel.org>
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: on builds/randconfigs (was: [PATCH -next] thermal: depends on NET)

On 01/11/11 21:18, Len Brown wrote:
>>> --- linux-next-20101213.orig/drivers/thermal/Kconfig
>>> +++ linux-next-20101213/drivers/thermal/Kconfig
>>> @@ -4,6 +4,7 @@
>>>  
>>>  menuconfig THERMAL
>>>  	tristate "Generic Thermal sysfs driver"
>>> +	depends on NET
> 
> I've added this line to the offending patch.

Thank you.

> 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?
"what is good for the goose is not good for the gander"

> Perhaps it would be a good idea to spend some time
> making non-useful configs impossible, and thus focus
> the testing where it will be of more benefit?

We have a plethora of kernel configs, so yes,
I'd be glad to see your efforts in that area.


Here's my take on kernel builds:

Ideally (randconfig) build testing wouldn't be needed
and developers would:

- know what kernel facilities their code uses and #include
  header files for all of them

- know what kernel configs their code uses and make their code
  depend on or select the needed config symbols

- actually read & review build output to look for errors and
  warnings in their code and not ignore them but actually fix them

- use sparse to check for other warnings

The current attitude of "if it builds, then it must be OK"
is not good.


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
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/