Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751955AbdFSRcm (ORCPT ); Mon, 19 Jun 2017 13:32:42 -0400 Received: from mx2.suse.de ([195.135.220.15]:34055 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751839AbdFSRck (ORCPT ); Mon, 19 Jun 2017 13:32:40 -0400 Date: Mon, 19 Jun 2017 19:32:38 +0200 From: "Luis R. Rodriguez" To: Greg Kroah-Hartman Cc: "Luis R. Rodriguez" , Sumit Semwal , Brian Norris , Kees Cook , Fengguang Wu , shuah@kernel.org, LKML , stable@vger.kernel.org, linux-kselftest@vger.kernel.org, yi1.li@linux.intel.com, takahiro.akashi@linaro.org, Martin Fuzzey , Alan Cox Subject: Re: LTS testing with latest kselftests - some failures Message-ID: <20170619173238.GG21846@wotan.suse.de> References: <20170616164651.GA21846@wotan.suse.de> <20170616192952.GA22037@kroah.com> <20170616194721.GE21846@wotan.suse.de> <20170617041635.GA26923@kroah.com> <20170619144805.GF21846@wotan.suse.de> <20170619145501.GA2400@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170619145501.GA2400@kroah.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1635 Lines: 29 On Mon, Jun 19, 2017 at 10:55:01PM +0800, Greg Kroah-Hartman wrote: > On Mon, Jun 19, 2017 at 04:48:05PM +0200, Luis R. Rodriguez wrote: > > On Sat, Jun 17, 2017 at 06:16:35AM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Jun 16, 2017 at 09:47:21PM +0200, Luis R. Rodriguez wrote: > > > > Some of the knobs however are for extending tests for > > > > existing APIs in older kernels, the async and custom fallback one are an > > > > example. There are a series of test cases later added which could help > > > > test LTS kernels. Would Linaro pick these test driver enhancements to help > > > > increase coverage of tests? Or is it not worth it? If its worth it then > > > > what I was curious was how to help make this easier for this process to > > > > bloom. > > > > > > I don't understand, what do you mean by "pick these test driver > > > enhancements"? What kind of "knobs" are there in tests? Shouldn't the > > > tests "just work" with no kind of special configuration of the tests be > > > needed? No user is going to know to enable something special. > > > > Test driver knobs, so for instance the async and custom patches referenced > > enable the shell script to use the async api and the custom API. > > Ah, testing kernel code, that makes more sense. I don't really know, if > the apis are present in the older kernel trees, I don't have a problem > having them be backported to stable kernel releases, as this isn't code > that people are actually running on a "normal" system. Wonderful, will peg test-driver changes as stable then when this fits. I really do think this will make test coverage better. Luis