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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 2 Sep 2020 14:23:00 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Alex Elder <elder@...aro.org>
Cc:     Randy Dunlap <rdunlap@...radead.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Networking <netdev@...r.kernel.org>
Subject: Re: COMPILE_TEST

> > 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
> 
> The above could only be done if the dependency is simply for
> linkage and not functionality.  Maybe that makes sense in
> some cases but it seems like a mistake.

It depends on the subsystem. debugfs is totally optional and you
should not be able to tell if it is enabled or not from what its API
returns.

Most subsystems stubs will return -EOPNOTSUPP. If the driver does
every get probed, it is then likely to fail in a controlled manor.

As the name implies COMPILE_TEST is all about build tested, and less
about boot testing. There might be some test farms which actually boot
kernels compiled with COMPILE_TEST, but that in itself should not be a
problem. Drivers only get probed if there is some indication the
hardware actually exists, PCI enumeration, USB enumeration, device
tree, etc.

      Andrew