Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751868AbdFHPh6 (ORCPT ); Thu, 8 Jun 2017 11:37:58 -0400 Received: from mail-wr0-f171.google.com ([209.85.128.171]:36139 "EHLO mail-wr0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751629AbdFHPh5 (ORCPT ); Thu, 8 Jun 2017 11:37:57 -0400 MIME-Version: 1.0 From: Tom Gall Date: Thu, 8 Jun 2017 10:37:55 -0500 Message-ID: Subject: kselftest backports? To: stable@vger.kernel.org, linux-kernel@vger.kernel.org, shuah@kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v58Fc3Bg003452 Content-Length: 1209 Lines: 35 We've been running kselftests for ARM and x86 hardware in an effort to detect regressions in various kernels including LTS and candidate patches. One general question we've had is what's the right thing to do when it comes to running kselftest on older LTS kernels. Let's pick on 4.4 for the purposes of this discussion tho obviously the example applies to other versions. 1) Run current top of tree, kselftest on a 4.4 LTS? 2) Run kselftest from 4.4 on 4.4 LTS? #1 gets latest greatest set of tests but obviously there can be breakage because of how the kernel evolves over time. #2 misses tests that are later developed but otherwise fine Regardless of the right answer, some obvious questions but I'll ask anyway: -) Shouldn't new additions to kselftest that work on older kernels be backported and submitted on the stable list? -) In the case where some test is kernel version specific for whatever reason, I presume building in version detection into kselftest makes sense? Thanks. -- Regards, Tom Director, Linaro Mobile Group Linaro.org │ Open source software for ARM SoCs irc: tgall_foo | @tom_gall "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian