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 ESMTP id 2CCDD85D for ; Fri, 6 Jun 2014 09:10:20 +0000 (UTC) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 147C31F899 for ; Fri, 6 Jun 2014 09:10:19 +0000 (UTC) Message-ID: <53918574.3090307@hitachi.com> Date: Fri, 06 Jun 2014 18:10:12 +0900 From: Masami Hiramatsu MIME-Version: 1.0 To: Daniel Vetter References: <537F3551.2070104@hitachi.com> <20140528153702.GU23991@suse.de> <20140528185748.GA30673@kroah.com> <20140605002331.GB24037@kroah.com> <20140605065455.GM10819@suse.de> <539051E4.3040708@hitachi.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [CORE TOPIC] kernel testing standard List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , (2014/06/05 20:58), Daniel Vetter wrote: > On Thu, Jun 5, 2014 at 1:17 PM, Masami Hiramatsu > wrote: >> (2014/06/05 17:53), Daniel Vetter wrote: >>> On Thu, Jun 5, 2014 at 10:30 AM, Geert Uytterhoeven >>> wrote: >>>> On Thu, Jun 5, 2014 at 8:54 AM, Mel Gorman wrote: >>>>> There is a hazard that someone bisecting the tree would need to be careful >>>>> to not bisect LTP instead. >>>> >>>> That may actually be a good reason not to import LTP... >>>> I'd imagine you usually want to bisect the kernel to find when a regression >>>> was introduced in the syscall API. >>>> >>>> Is there a reason not to run the latest version of LTP (unless bisecting >>>> LTP ;-)? The syscall API is supposed to be stable. >>> >>> Same for validating backports - you want the latest testsuite to make >>> sure you don't miss important fixes. Downside is that the testsuite >>> needs to be compatible over a much wider range of kernels to be >>> useful, which is a pain for e.g. checking that garbage in reserved >>> fields (like reserved flags) are properly rejected on each kernel >>> version. >> >> Perhaps, the testsuite can recognize which patch is merged or not >> if it can access the git repository by "git log | grep " >> or something like that. Then, it can self-configure to reject >> non-supported test. :) > > Well we have feature flags and stuff (need them anyway) and magic > macros to skip tests if something isn't there/supported. So (at least > for us) not a technical issue at all. Nice :) , and I think we can use git commit-id as feature flags in other subsystems. Since the patches in stable tree have [ Upstream commit ] tag in the description, we can use them for checking which fixes are already merged. > The problem is in getting these > tests right in all cases and maintaining them while updating tests for > new features. Is that a limitation comes from feature flags? or version synchronizing problem? Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com