netdev - Re: COMPILE

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: <18f4418f-0ca0-bd5d-10fc-998b4689f9e5@infradead.org>
Date:   Tue, 1 Sep 2020 17:52:58 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>
Cc:     Alex Elder <elder@...aro.org>, Networking <netdev@...r.kernel.org>
Subject: Re: COMPILE_TEST

On 9/1/20 5:17 PM, Jakub Kicinski wrote:
> On Tue, 1 Sep 2020 23:48:52 +0200 Andrew Lunn wrote:
>> On Tue, Sep 01, 2020 at 03:22:31PM -0500, Alex Elder wrote:
>>> Jakub, you suggested/requested that the Qualcomm IPA driver get
>>> built when the COMPILE_TEST config option is enabled.  I started
>>> working on this a few months ago but didn't finish, and picked
>>> it up again today.  I'd really like to get this done soon.
>>>
>>> The QCOM_IPA config option depends on and selects other things,
>>> and those other things depend on and select still more config
>>> options.  I've worked through some of these, but now question
>>> whether this is even the right approach.  Should I try to ensure
>>> all the code the IPA driver depends on and selects *also* gets
>>> built when COMPILE_TEST is enabled?  Or should I try to minimize
>>> the impact on other code by making IPA config dependencies and
>>> selections also depend on the value of COMPILE_TEST?
>>>
>>> Is there anything you know of that describes best practice for
>>> enabling a config option when COMPILE_TEST is enabled?  
>>
>> Hi Alex
>>
>> In general everything which can be build with COMPILE_TEST should be
>> built with COMPILE_TEST. So generally it just works, because
>> everything selected should already be selected because they already
>> have COMPILE_TEST.
>>
>> Correctly written drivers should compile for just about any
>> architecture. If they don't it suggests they are not using the APIs
>> correctly, and should be fixed.
>>
>> If the dependencies have not had COMPILE_TEST before, you are probably
>> in for some work, but in the end all the drivers will be of better
>> quality, and get build tested a lot more.
> 
> Nothing to add :) I'm not aware of any codified best practices.
> 

I have a little to add, but maybe some can complete this more
than I can.

Several subsystem header files add stubs for when that subsystem is not
enabled.  I know <linux/of.h> works with CONFIG_OF=y or =n, with lots of stubs.

Same is true for <linux/gpio.h> and CONFIG_GPIOLIB.

It would be good to know which other CONFIG symbols and header files
are known to work (or expected to work) like this.

Having these stubs allows us to always either omit e.g.
	depends on GPIOLIB
or make it say
	depends on GPIOLIB || COMPILE_TEST


Also, there are $ARCH conditions whose drivers also usually
could benefit from COMPILE_TEST, so we often see for a driver:

	depends on MIPS || COMPILE_TEST
or
	depends on ARCH_some_arm_derivative || COMPILE_TEST
or
	depends on *PLATFORM* || COMPILE_TEST
or
	depends on ARCH_TEGRA || COMPILE_TEST

So if a driver is destined (or designed) for one h/w environment,
we very much want to build it with COMPILE_TEST for other h/w platforms.


HTH.
-- 
~Randy