Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] & [TECH TOPIC] Improve regression tracking

[Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>]

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