On Wed, Aug 02, 2017 at 12:42:04PM -0600, Shuah Khan wrote: > >>> $ make O=$PWD-build -j8 kselftests > >>> make[1]: Entering directory 'linux-build' > >>> make[1]: *** No rule to make target 'kselftests'. Stop. > >>> make[1]: Leaving directory 'linux-build' > >>> Makefile:145: recipe for target 'sub-make' failed > >>> make: *** [sub-make] Error 2 > > There are multiple ways to run selftests at the moment. If your > preferred use-case isn't supported, I don't see why it can't be > added. There are many of us who use separate object directories so we can build the same kernel tree with multiple configurations. So for example, my kernel sources will be on an SSD, but sometimes my /build directory will be on a HDD since storing the object files on an HDD don't really buy as much as keeping the sources on SSD. For example, so I might be doing builds via: make O=/build/ext4 -j8 and make O=/build/ext4-32 ARCH=i386 -j8 Or someone might have a separate config file for doing debugging which is different from their production kernel, which they could do by having a different .config file in /build/ext4-debug/.config. > >> It is "make kselftest" > > > > If I include the standard O= to keep my source tree pristine > > it still fails. Which is a practical issue. Especially because > > that "make kselftest" needs to be followed by I think "make mrproper" > > to get back to my normal development workflow. > > Hmm. not sure why you would need to run "make mrproper" after running > "make kselftest" - I never have to. I would like to understand why though > if you are seeing problems without running "make mrproper". The problem is that if you are doing builds in separate object directories, you must not have any build files in the source tree. Otherwise make gets terribly confused. If you have done a build in the source tree, then "make O=..." will because the Kernel makefile system has safety check which detects this case and complains: % make O=/build/linux-build make[1]: Entering directory '/build/linux-build' CHK include/config/kernel.release GEN ./Makefile CHK include/generated/uapi/linux/version.h CHK scripts/mod/devicetable-offsets.h Using /home/tytso/linux/linux as source for kernel /home/tytso/linux/linux is not clean, please run 'make mrproper' ... So this is why Eric said that he has to run "make mrproper" after doing "make kselftest". That's because doing any kind of build in the source tree breaks his (and my) normal kernel building system. Personally, I do all of my testing using xfstests (and gce-xfstests in particular). And so I don't have a lot of reason to spend time making kselftest work with the "make O=xxx" build paradigm. It's fair to say the fact that kselftest doesn't work with my kernel development workflow hasn't helped my motivation to try it out. But as I told the systemtap folks many years ago --- "you're not under any obligation to support my workflow; but if systemtap is hostile to my kernel development workflow, you also can't expect me to help support and grow the use of systemtap, either. It works both ways." The same I think applies to kselftest. Telling developers who complain that kselftest doesn't work well with their workflow to "send a patch" may not result in the reaction that you hope. Especially for something as similar as "make O=xxx", which I think is a pretty common development workflow. Anyway, I hope someone will care enough about kselftest to help support "make O=xxx"; I have to admit that someone isn't me, though. Sorry; I just don't have the time.... Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
