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 2FE944C6 for ; Fri, 9 May 2014 05:34:02 +0000 (UTC) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 666E92021C for ; Fri, 9 May 2014 05:34:01 +0000 (UTC) Received: from mlsv2.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id E519433CCA for ; Fri, 9 May 2014 14:33:59 +0900 (JST) Received: from vshuts04.hitachi.co.jp (vshuts04.hitachi.co.jp [10.201.6.86]) by mfilter05.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id s495Xx31024480 for ; Fri, 9 May 2014 14:33:59 +0900 Message-ID: <536C68C3.5030500@hitachi.com> Date: Fri, 09 May 2014 14:33:55 +0900 From: Masami Hiramatsu MIME-Version: 1.0 To: ksummit-discuss@lists.linuxfoundation.org References: <53662254.9060100@huawei.com> <53699F27.9040403@hitachi.com> <1399431538.2581.30.camel@buesod1.americas.hpqcorp.net> <20140507090628.GZ26890@mwanda> <20140507141503.GB12433@quack.suse.cz> <536AFC26.2080907@huawei.com> <20140508094109.GA3685@quack.suse.cz> <20140509041140.GB22191@kroah.com> In-Reply-To: <20140509041140.GB22191@kroah.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Ksummit-discuss] [CORE TOPIC] stable issues List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , (2014/05/09 13:11), Greg KH wrote: > On Thu, May 08, 2014 at 01:35:45PM -0700, Andy Lutomirski wrote: >> On Thu, May 8, 2014 at 2:41 AM, Jan Kara wrote: >>> On Thu 08-05-14 11:38:14, Li Zefan wrote: >>>> On 2014/5/7 22:15, Jan Kara wrote: >>>>> On Wed 07-05-14 12:06:28, Dan Carpenter wrote: >>>>>> On Tue, May 06, 2014 at 07:58:58PM -0700, Davidlohr Bueso wrote: >>>>>>> I tend to think of LTP as a nice way of doing unit-tests for the uapi. >>>>>>> Fengguang's scripts do include it, iirc, but I'm referring more to unit >>>>>>> level tests. It serves well for changes in ipc, and should also for >>>>>>> other subsystems. >>>>>> >>>>>> LTP is too complicated and enterprisey. With trinity you don't can just >>>>>> type: >>>>>> >>>>>> ./configure.sh && make && ./trinity >>>>>> >>>>>> With LTP you have to read the install documents. You can't run it >>>>>> from your home directory so you have to build a virtual machine which >>>>>> you don't care about before you install it. >>>>> Actually, I'm occasionally using LTP and it doesn't seem too bad to me. >>>>> And it seems LTP is improving over time so I'm mostly happy about it. >>>> >>>> But how useful LTP is in finding kernel bugs? It seems to me we seldom >>>> see bug reports which say the bug was found by LTP? >>> I'm handling a few (3-5) per year. I'm also extending the coverage (e.g. >>> recently I've added fanotify interface coverage) when doing more involved >>> changes to some code so that LTP can be reasonably used for regression >>> checking. >> >> There was some talk about having some kind of 'make test' that you can >> type in a kernel tree. I'm not sure what the plan is, if any. > > The plan is to fix it, we already have it in the tree today, but it is > broken. So will the "make test" run tools/testing/selftest? or other tests? Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com