From: Theodore Ts'o <tytso@mit.edu> To: Shuah Khan <shuahkh@osg.samsung.com> Cc: ksummit-discuss@lists.linuxfoundation.org, Carlos O'Donell <carlos@redhat.com>, linux-api@vger.kernel.org, Thorsten Leemhuis <linux@leemhuis.info>, Shuah Khan <shuah@kernel.org> Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] & [TECH TOPIC] Improve regression tracking Date: Wed, 2 Aug 2017 23:03:27 -0400 [thread overview] Message-ID: <20170803030327.gf7pl7foer3abdpe@thunk.org> (raw) In-Reply-To: <92c31d6f-f98d-c764-eeec-bd0a2316d769@osg.samsung.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org> To: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> Cc: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>, Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>, Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org, Carlos O'Donell <carlos-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Thorsten Leemhuis <linux-rCxcAJFjeRkk+I/owrrOrA@public.gmane.org>, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Shuah Khan <shuah-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] & [TECH TOPIC] Improve regression tracking Date: Wed, 2 Aug 2017 23:03:27 -0400 [thread overview] Message-ID: <20170803030327.gf7pl7foer3abdpe@thunk.org> (raw) In-Reply-To: <92c31d6f-f98d-c764-eeec-bd0a2316d769-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> 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
next prev parent reply other threads:[~2017-08-03 3:03 UTC|newest] Thread overview: 144+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-07-02 17:51 [Ksummit-discuss] [MAINTAINERS SUMMIT] & [TECH TOPIC] Improve regression tracking Thorsten Leemhuis 2017-07-03 16:30 ` Steven Rostedt 2017-07-03 16:30 ` Steven Rostedt 2017-07-03 18:50 ` Dan Williams 2017-07-03 18:50 ` Dan Williams 2017-07-04 19:03 ` Thorsten Leemhuis 2017-07-04 19:03 ` Thorsten Leemhuis 2017-07-05 12:45 ` Steven Rostedt 2017-07-05 12:45 ` Steven Rostedt 2017-07-05 13:09 ` Carlos O'Donell 2017-07-05 13:09 ` Carlos O'Donell 2017-07-05 13:27 ` Steven Rostedt 2017-07-05 13:27 ` Steven Rostedt 2017-07-05 14:06 ` Greg KH 2017-07-05 14:06 ` Greg KH 2017-07-05 14:28 ` Carlos O'Donell 2017-07-05 14:28 ` Carlos O'Donell 2017-07-05 14:33 ` Steven Rostedt 2017-07-05 14:33 ` Steven Rostedt 2017-07-05 14:52 ` Mark Brown 2017-07-05 14:52 ` Mark Brown 2017-07-05 15:08 ` Carlos O'Donell 2017-07-05 15:08 ` Carlos O'Donell 2017-07-05 16:10 ` Steven Rostedt 2017-07-05 16:10 ` Steven Rostedt 2017-07-06 11:34 ` Laurent Pinchart 2017-07-06 11:34 ` Laurent Pinchart 2017-07-09 13:46 ` Thorsten Leemhuis 2017-07-09 13:46 ` Thorsten Leemhuis 2017-07-05 14:33 ` Mark Brown 2017-07-05 14:33 ` Mark Brown 2017-07-05 14:36 ` Steven Rostedt 2017-07-05 14:36 ` Steven Rostedt 2017-07-05 14:50 ` James Bottomley 2017-07-05 14:50 ` James Bottomley 2017-07-05 14:56 ` Steven Rostedt 2017-07-05 14:56 ` Steven Rostedt 2017-07-05 15:09 ` James Bottomley 2017-07-05 15:09 ` James Bottomley 2017-07-05 15:20 ` Mark Brown 2017-07-05 15:20 ` Mark Brown 2017-07-05 15:40 ` Geert Uytterhoeven 2017-07-05 15:40 ` Geert Uytterhoeven 2017-07-05 15:20 ` Steven Rostedt 2017-07-05 15:20 ` Steven Rostedt 2017-07-05 15:32 ` James Bottomley 2017-07-05 15:32 ` James Bottomley 2017-07-05 15:43 ` Steven Rostedt 2017-07-05 15:43 ` Steven Rostedt 2017-07-05 18:24 ` Daniel Vetter 2017-07-05 18:24 ` Daniel Vetter 2017-07-05 18:17 ` Daniel Vetter 2017-07-05 18:17 ` Daniel Vetter 2017-07-05 15:16 ` Guenter Roeck 2017-07-05 15:16 ` Guenter Roeck 2017-07-05 15:27 ` Steven Rostedt 2017-07-05 15:27 ` Steven Rostedt 2017-07-05 15:36 ` James Bottomley 2017-07-05 15:36 ` James Bottomley 2017-07-05 16:04 ` Steven Rostedt 2017-07-05 16:04 ` Steven Rostedt 2017-07-05 16:58 ` James Bottomley 2017-07-05 16:58 ` James Bottomley 2017-07-05 17:07 ` Steven Rostedt 2017-07-05 17:07 ` Steven Rostedt 2017-07-05 16:48 ` Guenter Roeck 2017-07-05 16:48 ` Guenter Roeck 2017-07-05 16:58 ` Dan Williams 2017-07-05 16:58 ` Dan Williams 2017-07-05 17:02 ` Steven Rostedt 2017-07-05 17:02 ` Steven Rostedt 2017-07-06 9:28 ` Mark Brown 2017-07-06 9:28 ` Mark Brown 2017-07-06 9:41 ` Daniel Vetter 2017-07-06 9:41 ` Daniel Vetter 2017-07-06 14:53 ` Theodore Ts'o 2017-07-06 14:53 ` Theodore Ts'o 2017-07-06 21:28 ` Daniel Vetter 2017-07-06 21:28 ` Daniel Vetter 2017-07-06 14:48 ` James Bottomley 2017-07-06 14:48 ` James Bottomley 2017-07-07 10:03 ` Mark Brown 2017-07-07 10:03 ` Mark Brown 2017-07-31 16:54 ` Eric W. Biederman 2017-07-31 16:54 ` Eric W. Biederman 2017-07-31 20:11 ` Steven Rostedt 2017-07-31 20:11 ` Steven Rostedt 2017-07-31 20:12 ` Eric W. Biederman 2017-07-31 20:12 ` Eric W. Biederman 2017-08-02 16:53 ` Shuah Khan 2017-08-02 16:53 ` Shuah Khan 2017-08-02 17:33 ` Eric W. Biederman 2017-08-02 17:33 ` Eric W. Biederman 2017-08-02 17:46 ` Shuah Khan 2017-08-02 17:46 ` Shuah Khan 2017-08-02 17:58 ` Shuah Khan 2017-08-02 17:58 ` Shuah Khan 2017-08-02 18:04 ` Eric W. Biederman 2017-08-02 18:04 ` Eric W. Biederman 2017-08-02 18:23 ` Randy Dunlap 2017-08-02 18:23 ` Randy Dunlap 2017-08-02 18:42 ` Shuah Khan 2017-08-02 18:42 ` Shuah Khan 2017-08-03 3:03 ` Theodore Ts'o [this message] 2017-08-03 3:03 ` Theodore Ts'o 2017-08-03 17:42 ` Bird, Timothy 2017-08-03 17:42 ` Bird, Timothy 2017-08-03 22:11 ` Shuah Khan 2017-08-03 22:11 ` Shuah Khan 2017-08-03 18:51 ` Shuah Khan 2017-08-03 18:51 ` Shuah Khan 2017-08-04 1:15 ` Theodore Ts'o 2017-08-04 1:15 ` Theodore Ts'o 2017-07-07 3:33 ` Fengguang Wu 2017-07-07 3:33 ` Fengguang Wu 2017-07-07 4:52 ` Frank Rowand 2017-07-07 4:52 ` Frank Rowand 2017-07-05 15:32 ` Greg KH 2017-07-05 15:32 ` Greg KH 2017-07-05 15:36 ` Carlos O'Donell 2017-07-05 15:36 ` Carlos O'Donell 2017-07-05 15:52 ` Steven Rostedt 2017-07-05 15:52 ` Steven Rostedt 2017-07-05 18:42 ` Greg KH 2017-07-05 18:42 ` Greg KH 2017-07-05 18:29 ` Daniel Vetter 2017-07-05 18:29 ` Daniel Vetter 2017-07-06 22:24 ` Shuah Khan 2017-07-06 22:24 ` Shuah Khan 2017-07-06 22:32 ` Steven Rostedt 2017-07-06 22:32 ` Steven Rostedt 2017-07-06 22:40 ` Shuah Khan 2017-07-06 22:40 ` Shuah Khan 2017-07-05 16:54 ` Dan Williams 2017-07-05 16:54 ` Dan Williams 2017-07-05 18:45 ` Greg KH 2017-07-05 18:45 ` Greg KH 2017-07-05 19:47 ` Dan Williams 2017-07-05 19:47 ` Dan Williams 2017-07-05 14:06 ` Carlos O'Donell 2017-07-05 14:06 ` Carlos O'Donell 2017-07-05 15:47 ` Mark Brown 2017-07-05 15:47 ` Mark Brown 2017-07-07 6:15 ` Andrei Vagin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170803030327.gf7pl7foer3abdpe@thunk.org \ --to=tytso@mit.edu \ --cc=carlos@redhat.com \ --cc=ksummit-discuss@lists.linuxfoundation.org \ --cc=linux-api@vger.kernel.org \ --cc=linux@leemhuis.info \ --cc=shuah@kernel.org \ --cc=shuahkh@osg.samsung.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.