From: Andrew Lunn <andrew@lunn.ch>
To: Alex Elder <elder@linaro.org>
Cc: Randy Dunlap <rdunlap@infradead.org>,
Jakub Kicinski <kuba@kernel.org>,
Networking <netdev@vger.kernel.org>
Subject: Re: COMPILE_TEST
Date: Wed, 2 Sep 2020 14:23:00 +0200 [thread overview]
Message-ID: <20200902122300.GA3071395@lunn.ch> (raw)
In-Reply-To: <1743f479-68c8-5f27-8d35-e17d5c96b60a@linaro.org>
> > 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
prev parent reply other threads:[~2020-09-02 12:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-01 20:22 COMPILE_TEST Alex Elder
2020-09-01 21:48 ` COMPILE_TEST Andrew Lunn
2020-09-02 0:17 ` COMPILE_TEST Jakub Kicinski
2020-09-02 0:52 ` COMPILE_TEST Randy Dunlap
2020-09-02 11:46 ` COMPILE_TEST Alex Elder
2020-09-02 12:23 ` Andrew Lunn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200902122300.GA3071395@lunn.ch \
--to=andrew@lunn.ch \
--cc=elder@linaro.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rdunlap@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).