On 11/28/18 12:56 PM, Rob Herring wrote:
That's just style or taste. I would prefer to use depends instead of select, but that's also just my preference.
On Thu, Nov 29, 2018 at 4:40 PM Randy Dunlap rdunlap@infradead.org wrote:
I prefer depends too, but Rob is the maintainer here.
On Mon, Dec 3, 2018 at 6:14 PM Brendan Higgins brendanhiggins@google.com wrote:
Well, we should be consistent, not the follow the whims of each maintainer.
Rob
On Tue, Dec 4, 2018 at 5:41 AM Rob Herring robh@kernel.org wrote:
Sorry, I don't think that came out the way I meant it. I don't really think we are consistent on this point across the kernel, and I don't feel very strongly about the point, so I was just looking to follow the path of least resistance. (I also just assumed Rob would keep us consistent within drivers/of/.)
I figure if we are running unit tests from the test runner script or from an automated system, you won't be hunting for dependencies for a single test every time you want to run a test, so select doesn't make it easier to configure in most imagined use cases.
KUNIT hypothetically should not depend on anything, so select should be safe to use.
On the other hand, if we end up being wrong on this point and KUnit gains widespread adoption, I would prefer not to be in a position where I have to change a bunch of configs all over the kernel because this example got copied and pasted.
On Wed, Dec 5, 2018 at 5:43 PM Brendan Higgins brendanhiggins@google.com wrote:
I meant across unittests, we should be consistent. All unittests do either "depends on KUNIT" or "select KUNIT". The question I would ask is does KUNIT need to be user visible or is useful to enable without any unittests enabled? With depends, a user has 2 options to go enable vs. 1 with select.
But if you want a global kill switch to turn off all unittests, then depends works better.
You'll be so happy that 100s of tests have been created using kunit, it won't be a big deal. :)
In any case, I wouldn't spend more time on this.
Rob
linux-kselftest-mirror@lists.linaro.org