Re: [Ksummit-discuss] [CORE TOPIC] stable issues

[Greg KH <greg@kroah.com>]

On Thu, May 08, 2014 at 01:35:45PM -0700, Andy Lutomirski wrote:
> On Thu, May 8, 2014 at 2:41 AM, Jan Kara <jack@suse.cz> 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.

thanks,

greg k-h