Re: [PATCH] tools/memory-model: Fix litmus-tests's file names for case-insensitive filesystem.

[Boqun Feng]

On Mon, Nov 11, 2024 at 10:15:30PM +0100, Sz"oke Benjamin wrote:
> 2024. 11. 11. 21:29 keltezéssel, Paul E. McKenney írta:
> > On Mon, Nov 11, 2024 at 08:56:34PM +0100, Sz"oke Benjamin wrote:
> > > 2024. 11. 11. 20:22 keltezéssel, Paul E. McKenney írta:
> > > > On Mon, Nov 11, 2024 at 07:52:50PM +0100, Sz"oke Benjamin wrote:
> > > > > 2024. 11. 11. 17:54 keltezéssel, Paul E. McKenney írta:
> > > > > > On Mon, Nov 11, 2024 at 05:42:47PM +0100, egyszeregy@xxxxxxxxxxx wrote:
> > > > > > > From: Benjamin Sz"oke <egyszeregy@xxxxxxxxxxx>
> > > > > > > 
> > > > > > > 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"oke <egyszeregy@xxxxxxxxxxx>
> > > > > > 
> > > > > > 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

No, because once you do a checkout to a commit that previous to your
changes, things are going to break again. The real "issue" is git use
case-sensitive file names, so unless you can rewrite the whole history,
your "solution" goes nowhere.

Regards,
Boqun

> effective and proper fix/solution which can be commited into the Linux
> kernel repo to fix it.