From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 591BFAB8 for ; Thu, 3 Aug 2017 22:11:36 +0000 (UTC) Received: from osg.samsung.com (ec2-52-27-115-49.us-west-2.compute.amazonaws.com [52.27.115.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id C232E14F for ; Thu, 3 Aug 2017 22:11:35 +0000 (UTC) To: "Bird, Timothy" , Theodore Ts'o References: <20170705112707.54d7f345@gandalf.local.home> <20170705130200.7c653f61@gandalf.local.home> <87zibkzgve.fsf@xmission.com> <87lgn1nac8.fsf@xmission.com> <61093c3f-6ad0-c033-a524-f2624f8d55ba@osg.samsung.com> <87r2wtluc1.fsf@xmission.com> <92c31d6f-f98d-c764-eeec-bd0a2316d769@osg.samsung.com> <20170803030327.gf7pl7foer3abdpe@thunk.org> From: Shuah Khan Message-ID: <1ee7b868-5b53-fbfb-f2f3-93e69b57e2ef@osg.samsung.com> Date: Thu, 3 Aug 2017 16:11:32 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Cc: "ksummit-discuss@lists.linuxfoundation.org" , Carlos O'Donell , "linux-api@vger.kernel.org" , Thorsten Leemhuis , Shuah Khan , Shuah Khan Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] & [TECH TOPIC] Improve regression tracking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shuah Khan Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] & [TECH TOPIC] Improve regression tracking Date: Thu, 3 Aug 2017 16:11:32 -0600 Message-ID: <1ee7b868-5b53-fbfb-f2f3-93e69b57e2ef@osg.samsung.com> References: <20170705112707.54d7f345@gandalf.local.home> <20170705130200.7c653f61@gandalf.local.home> <87zibkzgve.fsf@xmission.com> <87lgn1nac8.fsf@xmission.com> <61093c3f-6ad0-c033-a524-f2624f8d55ba@osg.samsung.com> <87r2wtluc1.fsf@xmission.com> <92c31d6f-f98d-c764-eeec-bd0a2316d769@osg.samsung.com> <20170803030327.gf7pl7foer3abdpe@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Bird, Timothy" , Theodore Ts'o Cc: "ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org" , Carlos O'Donell , "linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Thorsten Leemhuis , Shuah Khan , Shuah Khan List-Id: linux-api@vger.kernel.org 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