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  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

Powered by blists - more mailing lists