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

[Shuah Khan <shuahkh@osg.samsung.com>]

On 08/03/2017 11:42 AM, Bird, Timothy wrote:
> 
> 
>> -----Original Message-----
>> From: Theodore Ts'o on Wednesday, August 02, 2017 8:03 PM
>>
>> 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....
> 
> My preferred method of building for embedded boards also uses "make O=xxx"
> It's been on my to do list for a while to add support for that (KBUILD_OUTPUT)
> to kselftest, but it's one of those things I never got around to.
> 
> Now that I know it's blocking other kernel developers, I'll prioritize it higher.
> 
> Shuah - if no one else steps up to do this, I'll try to see if I can find time to
> do it in the next month or two (no promises).  I think support for KBUILD_OUTPUT
> (or "make O=xxx") is pretty important. 
>    -- Tim 
> 

Tim,

Thanks for the offer to help. I am going look into this and let you know if I need
help. There has been some work done to support KBUILD_OUTPUT. I have to check and
see if it can address this use-case. If it does, address it, great.

thanks,
-- Shuah