From: "Szőke Benjamin" <egyszeregy@freemail.hu>
To: paulmck@kernel.org
Cc: stern@rowland.harvard.edu, parri.andrea@gmail.com,
will@kernel.org, peterz@infradead.org, boqun.feng@gmail.com,
npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk,
luc.maranget@inria.fr, akiyks@gmail.com, dlustig@nvidia.com,
joel@joelfernandes.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, lkmm@lists.linux.dev,
torvalds@linux-foundation.org
Subject: Re: [PATCH] tools/memory-model: Fix litmus-tests's file names for case-insensitive filesystem.
Date: Mon, 11 Nov 2024 22:15:30 +0100 [thread overview]
Message-ID: <a42da186-195c-40af-b4ee-0eaf6672cf2c@freemail.hu> (raw)
In-Reply-To: <5acaaaa0-7c17-4991-aff6-8ea293667654@paulmck-laptop>
2024. 11. 11. 21:29 keltezéssel, Paul E. McKenney írta:
> On Mon, Nov 11, 2024 at 08:56:34PM +0100, Szőke Benjamin wrote:
>> 2024. 11. 11. 20:22 keltezéssel, Paul E. McKenney írta:
>>> On Mon, Nov 11, 2024 at 07:52:50PM +0100, Szőke Benjamin wrote:
>>>> 2024. 11. 11. 17:54 keltezéssel, Paul E. McKenney írta:
>>>>> On Mon, Nov 11, 2024 at 05:42:47PM +0100, egyszeregy@freemail.hu wrote:
>>>>>> From: Benjamin Szőke <egyszeregy@freemail.hu>
>>>>>>
>>>>>> The goal is to fix Linux repository for case-insensitive filesystem,
>>>>>> to able to clone it and editable on any operating systems.
>>>>>>
>>>>>> Rename "Z6.0+pooncelock+poonceLock+pombonce.litmus" to
>>>>>> "Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus".
>>>>>>
>>>>>> Signed-off-by: Benjamin Szőke <egyszeregy@freemail.hu>
>>>>>
>>>>> Ummm... Really?
>>>>>
>>>>> Just out of curiosity, which operating-system/filesystem combination are
>>>>> you working with? And why not instead fix that combination to handle
>>>>> mixed case?
>>>>>
>>>>> Thanx, Paul
>>>>
>>>> Windows and also MacOS is not case sensitive by default. My goal is to
>>>> improve Linux kernel source-tree, to able to develop it in any operating
>>>> systems for example via Visual Studio Code extensions/IntelliSense feature
>>>> or any similar IDE which is usable in any OS.
>>>
>>> Why not simply enable case sensitivity on the file tree in which you
>>> are processing Linux-kernel source code?
>>>
>>> For MacOS: https://discussions.apple.com/thread/251191099?sortBy=rank
>>> For Windows: https://learn.microsoft.com/en-us/windows/wsl/case-sensitivity
>>>
>>> In some cases it might work better to simply run a Linux VM on top of
>>> Windows or MacOS.
>>>
>>> They tell me that webservers already do this, so why not also for
>>> Linux-kernel source code?
>>
>> Why we not solve it as simple as it can in the source code of the Linux
>> kernel with renaming? It would be more robust and more durable to fix this
>> issue/inconviniant in the source as an overal complete solution. Nobody like
>> to figth with configuraition hell of Windows and MacOS, or build up a
>> diskspace consumer Virtual Linux with crappy GUI capapilities for coding big
>> things.
>>
>> Young developers will never be willing to join and contributing in Linux
>> kernel in the future if Linux kernel code is not editable in a high-quality,
>> easy-to-use IDE for, which is usable in any OS.
>
> There are a great number of software projects out there that use mixed
> case. Therefore, can an IDE that does not gracefully handle mixed case
> really be said to be either high quality or easy to use?
>
> In other words, you have the option of making the IDE handle this.
>
>> Need to improve this kind of things and simplify/modernize developing or
>> never will be solved the following issues:
>> https://www.youtube.com/watch?v=lJLw94pAcBY
>
> Sorry, but that video does not support your point. In fact, the presenter
> clearly states that this sort of tooling issue is not a real problem
> for the Linux kernel near the middle of that video.
>
> Thanx, Paul
>
>>>> There were some accepted patches which aim this same goal.
>>>> https://gitlab.freedesktop.org/drm/kernel/-/commit/231bb9b4c42398db3114c087ba39ba00c4b7ac2c
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/commit/?h=for-curr&id=8bf275d61925cff45568438c73f114e46237ad7e
>>>
>>> Fair enough, as it is the maintainer's choice. Which means that
>>> their accepting these case-sensitivity changes does not require other
>>> maintainers to do so.
>>>
>>> Thanx, Paul
>>>
>>>>>> ---
>>>>>> tools/memory-model/Documentation/locking.txt | 2 +-
>>>>>> tools/memory-model/Documentation/recipes.txt | 2 +-
>>>>>> tools/memory-model/litmus-tests/README | 2 +-
>>>>>> ...> Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus} | 0
>>>>>> 4 files changed, 3 insertions(+), 3 deletions(-)
>>>>>> rename tools/memory-model/litmus-tests/{Z6.0+pooncelock+poonceLock+pombonce.litmus => Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus} (100%)
>>>>>>
>>>>>> diff --git a/tools/memory-model/Documentation/locking.txt b/tools/memory-model/Documentation/locking.txt
>>>>>> index 65c898c64a93..42bc3efe2015 100644
>>>>>> --- a/tools/memory-model/Documentation/locking.txt
>>>>>> +++ b/tools/memory-model/Documentation/locking.txt
>>>>>> @@ -184,7 +184,7 @@ ordering properties.
>>>>>> Ordering can be extended to CPUs not holding the lock by careful use
>>>>>> of smp_mb__after_spinlock():
>>>>>> - /* See Z6.0+pooncelock+poonceLock+pombonce.litmus. */
>>>>>> + /* See Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus. */
>>>>>> void CPU0(void)
>>>>>> {
>>>>>> spin_lock(&mylock);
>>>>>> diff --git a/tools/memory-model/Documentation/recipes.txt b/tools/memory-model/Documentation/recipes.txt
>>>>>> index 03f58b11c252..35996eb1b690 100644
>>>>>> --- a/tools/memory-model/Documentation/recipes.txt
>>>>>> +++ b/tools/memory-model/Documentation/recipes.txt
>>>>>> @@ -159,7 +159,7 @@ lock's ordering properties.
>>>>>> Ordering can be extended to CPUs not holding the lock by careful use
>>>>>> of smp_mb__after_spinlock():
>>>>>> - /* See Z6.0+pooncelock+poonceLock+pombonce.litmus. */
>>>>>> + /* See Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus. */
>>>>>> void CPU0(void)
>>>>>> {
>>>>>> spin_lock(&mylock);
>>>>>> diff --git a/tools/memory-model/litmus-tests/README b/tools/memory-model/litmus-tests/README
>>>>>> index d311a0ff1ae6..e3d451346400 100644
>>>>>> --- a/tools/memory-model/litmus-tests/README
>>>>>> +++ b/tools/memory-model/litmus-tests/README
>>>>>> @@ -149,7 +149,7 @@ Z6.0+pooncelock+pooncelock+pombonce.litmus
>>>>>> spin_lock() sufficient to make ordering apparent to accesses
>>>>>> by a process not holding the lock?
>>>>>> -Z6.0+pooncelock+poonceLock+pombonce.litmus
>>>>>> +Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus
>>>>>> As above, but with smp_mb__after_spinlock() immediately
>>>>>> following the spin_lock().
>>>>>> diff --git a/tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+pombonce.litmus b/tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus
>>>>>> similarity index 100%
>>>>>> rename from tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+pombonce.litmus
>>>>>> rename to tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus
>>>>>> --
>>>>>> 2.47.0.windows.2
>>>>>>
>>>>
>>
There is a technical issue in the Linux kernel source tree's file naming/styles
in git clone command on case-insensitive filesystem.
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:
'tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+pombonce.litmus'
'tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus'
As you a maintainer, what is your suggestion to fix it in the source code of the
Linux kernel? Please send a real technical suggestion not just how could it be
done in an other way (which is out of the scope now).
Is my renaming patch correct to solve it? Question is what is the most effective
and proper fix/solution which can be commited into the Linux kernel repo to fix it.
next prev parent reply other threads:[~2024-11-11 21:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-11 16:42 [PATCH] tools/memory-model: Fix litmus-tests's file names for case-insensitive filesystem egyszeregy
2024-11-11 16:54 ` Paul E. McKenney
2024-11-11 18:52 ` Szőke Benjamin
2024-11-11 19:22 ` Paul E. McKenney
2024-11-11 19:56 ` Szőke Benjamin
2024-11-11 20:29 ` Paul E. McKenney
2024-11-11 21:15 ` Szőke Benjamin [this message]
2024-11-11 21:23 ` Boqun Feng
2024-11-11 21:39 ` Szőke Benjamin
2024-11-11 21:44 ` Boqun Feng
2024-11-11 21:52 ` Paul E. McKenney
2024-11-11 22:00 ` Linus Torvalds
2024-11-11 23:21 ` Szőke Benjamin
2024-11-12 1:02 ` Boqun Feng
2024-11-12 10:06 ` Szőke Benjamin
2024-11-12 16:43 ` Paul E. McKenney
2024-11-12 16:56 ` Boqun Feng
2024-11-12 0:59 ` Alan Stern
2024-11-12 4:20 ` Paul E. McKenney
2024-11-12 15:35 ` Alan Stern
2024-11-12 18:26 ` Paul E. McKenney
2024-11-12 20:20 ` Alan Stern
2024-11-12 21:53 ` Paul E. McKenney
2024-12-12 23:09 ` Szőke Benjamin
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=a42da186-195c-40af-b4ee-0eaf6672cf2c@freemail.hu \
--to=egyszeregy@freemail.hu \
--cc=akiyks@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=j.alglave@ucl.ac.uk \
--cc=joel@joelfernandes.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkmm@lists.linux.dev \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).