mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: lyang0 <lei.yang@windriver.com>
To: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Shuah Khan <shuahkh@osg.samsung.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Shuah Khan <shuah@kernel.org>
Subject: Re: [PATCH] selftests: remove obsolete kconfig fragment for cpu-hotplug
Date: Fri, 3 Nov 2017 15:34:31 +0800	[thread overview]
Message-ID: <af2d0d4c-4cf2-ad6d-5b70-d46affbf5f07@windriver.com> (raw)
In-Reply-To: <CAO_48GGhdG_51=ckzchUiZKfNjwe79afRXbnaSjnmzcq2VeJvg@mail.gmail.com>



On 2017年11月03日 11:55, Sumit Semwal wrote:
> Hello Lei,
>
> On 2 November 2017 at 07:43, lyang0 <lei.yang@windriver.com> wrote:
>>
>> On 2017年11月02日 06:59, Shuah Khan wrote:
>>> On 11/01/2017 04:52 PM, Thomas Gleixner wrote:
>>>> On Wed, 1 Nov 2017, Shuah Khan wrote:
>>>>> On 10/17/2017 08:10 PM, lei.yang@windriver.com wrote:
>>>>>> From: Lei Yang <Lei.Yang@windriver.com>
>>>>>>
>>>>>> Kconfig CONFIG_CPU_NOTIFIER_ERROR_INJECT has been removed since kernel
>>>>>> 4.10
>>>>>> check commit:
>>>>>>       commit 530e9b76ae8f863dfdef4a6ad0b38613d32e8c3f
>>>>>>       Author: Thomas Gleixner <tglx@linutronix.de>
>>>>>>       Date:   Wed Dec 21 20:19:53 2016 +0100
>>>>>>
>>>>>>           cpu/hotplug: Remove obsolete cpu hotplug register/unregister
>>>>>> functions
>>>>>>
>>>>>>           hotcpu_notifier(), cpu_notifier(), __hotcpu_notifier(),
>>>>>> __cpu_notifier(),
>>>>>>           register_hotcpu_notifier(), register_cpu_notifier(),
>>>>>>           __register_hotcpu_notifier(), __register_cpu_notifier(),
>>>>>>           unregister_hotcpu_notifier(), unregister_cpu_notifier(),
>>>>>>           __unregister_hotcpu_notifier(), __unregister_cpu_notifier()
>>>>>>        <snip>
>>>>>>
>>>>>> Signed-off-by: Lei Yang <Lei.Yang@windriver.com>
>>>>>> ---
>>>>>>    tools/testing/selftests/cpu-hotplug/config | 1 -
>>>>>>    1 file changed, 1 deletion(-)
>>>>>>
>>>>>> diff --git a/tools/testing/selftests/cpu-hotplug/config
>>>>>> b/tools/testing/selftests/cpu-hotplug/config
>>>>>> index e6ab090..d4aca2a 100644
>>>>>> --- a/tools/testing/selftests/cpu-hotplug/config
>>>>>> +++ b/tools/testing/selftests/cpu-hotplug/config
>>>>>> @@ -1,2 +1 @@
>>>>>>    CONFIG_NOTIFIER_ERROR_INJECTION=y
>>>>>> -CONFIG_CPU_NOTIFIER_ERROR_INJECT=m
>>>>>>
>>>>> Yes. It is removed from the kernel. However, selftests from the latest
>>>>> release do get run routinely on older stable releases. Dropping the
>>>>> config will impact coverage on older releases.
>>>>>
>>>>> Thomas/Greg,
>>>>>
>>>>> Any ideas on what we should do about this. On one hand it is a good idea
>>>>> to remove it, however my concern is coverage on older releases.
>>>> Can you check the kernel version on which you are running and do it
>>>> runtime
>>>> conditionally?
>>>>
>>> I have been avoiding adding kernel version checks to tests. Maybe this is
>>> one exception since the functionality is obsoleted.
>>
>>
>> I think the baseline is that we only assure kselftest  works on the release
>> it belongs to, for example, removing this config for the
>> version above 4.10, keep it in old release.  but looks it doesn't work like
>> this way.
>>
>> I think We can't  assure latest kselftest works still well on a very older
>> releases
>> yes, for some features it's common for each release. but we have some
>> features that are only available in newer
>> release.   even for the common features, it's difficult to make sure it
>> still works well for each
>> release. maintenance is a big effort if we use something like version check.
>> you never know what changes will make
>> for general feature in the future release although it's common right now.
> As Greg and several others have reiterated - the tests should be able
> to check for presence of a feature, run it if it's applicable, and
> skip if it's not. It really isn't about kernel version check, but
> writing code and test in such a way that tests can 'degrade
> gracefully', rather than fail. There are several good examples for the
> same.
>
> The idea of running newer tests is to gain coverage on older kernels
> for features still present in them, but tests weren't available at the
> time of the kernel tagging.

so we actually don't have version control for kselftest?  anytime, we 
use the latest one

I thought  we recommended use the one in 4.12 if we want to test 4.12 
kernel, not to use the one in newer version



> Hope this helps clear the doubt?

I'm wondering how do you determine this patch apply to which release.

I don't understand "Dropping the config will impact coverage on older 
releases" , we can just don't apply it to
the release older than 4.10.  then the coverage doesn't drop.

Lei



>> Lei
>>
>>
>>> In any case, just removing the config isn't the complete solution. I will
>>> have to think about this some.
>>>
>>> thanks,
>>> -- Shuah
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kselftest"
>>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> Best,
> Sumit.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-11-03  7:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-18  2:10 lei.yang
2017-11-01 22:14 ` Shuah Khan
2017-11-01 22:52   ` Thomas Gleixner
2017-11-01 22:59     ` Shuah Khan
2017-11-02  2:13       ` lyang0
2017-11-03  3:55         ` Sumit Semwal
2017-11-03  7:34           ` lyang0 [this message]
2017-11-02  8:46   ` Greg Kroah-Hartman
2017-11-02 22:14 ` Shuah Khan
2017-11-02 22:25   ` Yang, Lei
2017-11-03 14:03   ` lei yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=af2d0d4c-4cf2-ad6d-5b70-d46affbf5f07@windriver.com \
    --to=lei.yang@windriver.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=shuahkh@osg.samsung.com \
    --cc=sumit.semwal@linaro.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®