On 08/02/2017 09:03 PM, Theodore Ts'o wrote: > 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. Thanks for the detailed explanation. I have a better understanding of the workflow. > > 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. Now that I have a better understanding, I will take a look. Based on quick look, it might not be difficult to support it. > > 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.... > It wasn't my intent to be hostile. thanks, -- Shuah -- 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
