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

["Bird, Timothy" <Tim.Bird@sony.com>]

> -----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