From: Shuah Khan <skhan@linuxfoundation.org>
To: Dev Jain <dev.jain@arm.com>, shuah@kernel.org, oleg@redhat.com
Cc: mingo@kernel.org, tglx@linutronix.de, mark.rutland@arm.com,
ryan.roberts@arm.com, broonie@kernel.org, suzuki.poulose@arm.com,
Anshuman.Khandual@arm.com, DeepakKumar.Mishra@arm.com,
aneesh.kumar@kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org, sj@kernel.org,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH v6 1/2] selftests: Rename sigaltstack to generic signal
Date: Mon, 9 Sep 2024 11:54:37 -0600 [thread overview]
Message-ID: <cb2f88e0-8e31-43a0-a5ea-03f0ab05417e@linuxfoundation.org> (raw)
In-Reply-To: <03c5b10d-b81c-4074-9c27-8ffc8c7fc84a@arm.com>
On 9/8/24 23:16, Dev Jain wrote:
>
> On 9/7/24 01:29, Shuah Khan wrote:
>> On 9/4/24 23:56, Dev Jain wrote:
>>>
>>> On 9/4/24 22:35, Shuah Khan wrote:
>>>> On 9/3/24 22:52, Dev Jain wrote:
>>>>>
>>>>> On 9/4/24 03:14, Shuah Khan wrote:
>>>>>> On 8/30/24 10:29, Dev Jain wrote:
>>>>>>>
>>>>>>> On 8/27/24 17:16, Dev Jain wrote:
>>>>>>>>
>>>>>>>> On 8/27/24 17:14, Shuah Khan wrote:
>>>>>>>>> On 8/22/24 06:14, Dev Jain wrote:
>>>>>>>>>> Rename sigaltstack to generic signal directory, to allow adding more
>>>>>>>>>> signal tests in the future.
>>>>>>>>>
>>>>>>>>> Sorry - I think I mentioned I don't like this test renamed. Why are you sending
>>>>>>>>> this rename still included in the patch series?
>>>>>>>>
>>>>>>>> I am not renaming the test, just the directory. The directory name
>>>>>>>> is changed to signal, and I have retained the name of the test -
>>>>>>>> sas.c.
>>>>>>>
>>>>>>> Gentle ping: I guess there was a misunderstanding; in v5, I was
>>>>>>> also changing the name of the test, to which you objected, and
>>>>>>> I agreed. But, we need to change the name of the directory since
>>>>>>> the new test has no relation to the current directory name,
>>>>>>> "sigaltstack". The patch description explains that the directory
>>>>>>> should be generically named.
>>>>>>>
>>>>>>
>>>>>> Right. You are no longer changing the test name. You are still
>>>>>> changing the directory name. The problem I mentioned stays the
>>>>>> same. Any fixes to the existing tests in this directory can no
>>>>>> longer auto applied to stables releases.
>>>>>
>>>>> I understand your point, but commit baa489fabd01 (selftests/vm: rename
>>>>> selftests/vm to selftests/mm) is also present. That was a lot bigger change;
>>>>> sigaltstack contains just one test currently, whose fixes possibly would have
>>>>> to be backported, so I guess it should not be that much of a big problem?
>>>>>
>>>>>>
>>>>
>>>> So who does the backports whenevenr something changes? You are adding
>>>> work where as the automated process would just work without this
>>>> change. It doesn't matter if there is another test that changed
>>>> the name.
>>>>
>>>>>> Other than the desire to rename the directory to generic, what
>>>>>> other value does this change bring?
>>>>>
>>>>> Do you have an alternative suggestion as to where I should put my new test then;
>>>>> I do not see what is the value of creating another directory to just include
>>>>> my test. This will unnecessarily clutter the selftests/ directory with
>>>>> directories containing single tests. And, putting this in "sigaltstack" is just
>>>>> wrong since this test has no relation with sigaltstack.
>>>>>
>>>>
>>>> If this new test has no relation to sigaltstack, then why are you changing
>>>> and renaming the sigaltstack directory?
>>>
>>> Because the functionality I am testing is of signals, and signals are a superset
>>> of sigaltstack. Still, I can think of a compromise, if semantically you want to
>>> consider the new test as not testing signals, but a specific syscall "sigaction"
>>> and its interaction with blocking of signals, how about naming the new directory "sigaction"?
>>>> Adding a new directory is much better
>>>> than going down a path that is more confusing and adding backport overhead.
>>>>
>>
>> Okay - they are related except that you view signalstack as a subset
>> of signals. I saw Mark's response as well saying sigaction isn't
>> a good name for this.
>>
>> Rename usually wipe out git history as well based on what have seen
>> in the past.
>>
>> My main concern is backports. Considering sigstack hasn't changed
>> 2021 (as Mark's email), let's rename it.
>>
>> I am reluctantly agreeing to the rename as it seems to make sense
>> in this case.
>
> Thanks! I guess there is no update required from my side, and you can
> pull this series?
>>
I can pull this with x86v maintainer ack.
Or to go through x86 tree:
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
next prev parent reply other threads:[~2024-09-09 17:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-22 12:14 [PATCH v6 0/2] Add test to distinguish between thread's signal mask and ucontext_t Dev Jain
2024-08-22 12:14 ` [PATCH v6 1/2] selftests: Rename sigaltstack to generic signal Dev Jain
2024-08-27 11:44 ` Shuah Khan
2024-08-27 11:46 ` Dev Jain
2024-08-30 16:29 ` Dev Jain
2024-09-03 21:44 ` Shuah Khan
2024-09-04 4:52 ` Dev Jain
2024-09-04 17:05 ` Shuah Khan
2024-09-05 5:56 ` Dev Jain
2024-09-05 11:25 ` Mark Brown
2024-09-06 19:59 ` Shuah Khan
2024-09-09 5:16 ` Dev Jain
2024-09-09 17:54 ` Shuah Khan [this message]
2024-09-16 3:58 ` Dev Jain
2024-10-07 4:37 ` Dev Jain
2024-10-07 14:45 ` Mark Brown
2024-08-22 12:14 ` [PATCH v6 2/2] selftests: Add a test mangling with uc_sigmask Dev Jain
-- strict thread matches above, loose matches on Subject: below --
2024-08-22 12:09 [PATCH v6 0/2] Add test to distinguish between thread's signal mask and ucontext_t Dev Jain
2024-08-22 12:09 ` [PATCH v6 1/2] selftests: Rename sigaltstack to generic signal Dev Jain
2024-08-22 12:11 ` Dev Jain
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=cb2f88e0-8e31-43a0-a5ea-03f0ab05417e@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=Anshuman.Khandual@arm.com \
--cc=DeepakKumar.Mishra@arm.com \
--cc=aneesh.kumar@kernel.org \
--cc=broonie@kernel.org \
--cc=dev.jain@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=ryan.roberts@arm.com \
--cc=shuah@kernel.org \
--cc=sj@kernel.org \
--cc=suzuki.poulose@arm.com \
--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