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

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

[egyszeregy]

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>
---
 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

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

[Paul E. McKenney]

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

> ---
>  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
> 

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

[Szőke Benjamin]

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.

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


> 
>> ---
>>   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
>>

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

[Paul E. McKenney]

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?

> 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
> > > 
> 

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

[Szőke Benjamin]

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.

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

> 
>> 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
>>>>
>>

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

[Paul E. McKenney]

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
> > > > > 
> > > 
> 

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

[Szőke Benjamin]

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.

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@freemail.hu wrote:
> > > > > > > From: Benjamin Sz"oke <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"oke <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

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.

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

[Szőke Benjamin]

2024. 11. 11. 22:23 keltezéssel, Boqun Feng írta:
> 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@freemail.hu wrote:
>>>>>>>> From: Benjamin Sz"oke <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"oke <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
> 
> 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.


My renaming solution can not fix the old history line, but after this patch in 
latest master branch there are no any issue anymore, in git cloning. This the 
bare minimum solution which can fix its "cloning" issue for the future.

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

[Boqun Feng]

On Mon, Nov 11, 2024 at 10:39:07PM +0100, Sz"oke Benjamin wrote:
[...]
> > > 
> > > 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.
> 
> 
> My renaming solution can not fix the old history line, but after this patch
> in latest master branch there are no any issue anymore, in git cloning. This
> the bare minimum solution which can fix its "cloning" issue for the future.

You asked for a technical issue for doing the renaming, and I gave you
one: simply renaming doesn't solve the issue you want to resolve,
develop Linux kernel on a case-insensitive filesystem. Do you admit that
the original issue won't get fixed with your patch? Then technically,
the best way to "work around" it is to use a case-sensitive filesystem,
right?

Regards,
Boqun

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

[Paul E. McKenney]

On Mon, Nov 11, 2024 at 10:39:07PM +0100, Szőke Benjamin wrote:
> 2024. 11. 11. 22:23 keltezéssel, Boqun Feng írta:
> > 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@freemail.hu wrote:
> > > > > > > > > From: Benjamin Sz"oke <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"oke <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).

Fixing it in the IDEs is absolutely in scope from where I sit.

> > > 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.
> 
> My renaming solution can not fix the old history line, but after this patch
> in latest master branch there are no any issue anymore, in git cloning. This
> the bare minimum solution which can fix its "cloning" issue for the future.

Not so.  The issue will keep arising, both within the Linux kernel tree
and in other projects, repeatedly breaking your IDEs.  You will find
yourself playing an eternal game of whack-a-mole, a game that I have no
interest in participating in myself.

Sure, I worked on upper-case-only systems back in the 1970s and early
1980s, but that was a very long time ago.  Most of those systems had
six-bit bytes and all of them were programmed using either paper tape
or punched cards.

Single-case-only is just as obsolete as that paper tape and those
punched cards.

So fix the IDEs!!!

*Then* you will have solved the problem for the case of checking old
versions from the Linux-kernel git tree, new versions where mixed case
slipped back in, and for other projects as well, past, present and future.

If you are still not convinced, your other option is to convince Linus
Torvalds to give me a direct order instructing me to accept your patch.

And who knows?  He is quite young, so he might be easier to persuade.

Until then, the answer is "no".

							Thanx, Paul

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

[Linus Torvalds]

On Mon, 11 Nov 2024 at 13:15, Szőke Benjamin <egyszeregy@freemail.hu> wrote:
>
> There is a technical issue in the Linux kernel source tree's file naming/styles
> in git clone command on case-insensitive filesystem.

No.

This is entirely your problem.

The kernel build does not work, and is not intended to work on broken setups.

If you have a case-insensitive filesystem, you get to keep both broken parts.

I actively hate case-insensitive filesystems. It's a broken model in
so many ways. I will not lift a finger to try to help that
braindamaged setup.

"Here's a nickel, Kid. Go buy yourself a real computer"

             Linus

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

[Szőke Benjamin]

2024. 11. 11. 23:00 keltezéssel, Linus Torvalds írta:
> On Mon, 11 Nov 2024 at 13:15, Szőke Benjamin <egyszeregy@freemail.hu> wrote:
>>
>> There is a technical issue in the Linux kernel source tree's file naming/styles
>> in git clone command on case-insensitive filesystem.
> 
> No.
> 
> This is entirely your problem.
> 
> The kernel build does not work, and is not intended to work on broken setups.
> 
> If you have a case-insensitive filesystem, you get to keep both broken parts.
> 
> I actively hate case-insensitive filesystems. It's a broken model in
> so many ways. I will not lift a finger to try to help that
> braindamaged setup.
> 
> "Here's a nickel, Kid. Go buy yourself a real computer"
> 
>               Linus


In this patch my goal is to improve Linux kernel codebase to able to edit/coding 
in any platform, in an IDE which has a modern GUI.

Chillout, i am not so stupid to compile kernel on this "braindamaged setup", I 
just like to edit the code and manage it by git commands.

So, this is a tipical Braindamaged setup in 2024 for Generation of a half of Y 
(like me), Z and Alpha developers.

Windows or MacOS system
- Visual Studio Code for coding
     - Git for manage kernel source
     - IntelliSense in coding
     - Live coding with other developers

Linux remote server
- Visual Studio Code remote SSH extension/connection for Linux server
     - Sync kernel workdir with remote Ubuntu/Debian/RHEL Linux server
     - Remote SSH compile for X86_64, ARM64 etc ...
     - Download the build result

Instead of Visual Studio Code it can be possible to use JetBrains, Eclipse and 
so on any other modern IDE. The actual limitation is only, that there is a 
filename issue in the Linux kernel source with 
"Z6.0+pooncelock+poonceLock+pombonce.litmus", why git clone is failed to work 
well in this case-insensitive OSs.

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

[Boqun Feng]

On Tue, Nov 12, 2024 at 12:21:51AM +0100, Sz"oke Benjamin wrote:
> 2024. 11. 11. 23:00 keltezéssel, Linus Torvalds írta:
> > On Mon, 11 Nov 2024 at 13:15, Sz"oke Benjamin <egyszeregy@freemail.hu> wrote:
> > > 
> > > There is a technical issue in the Linux kernel source tree's file naming/styles
> > > in git clone command on case-insensitive filesystem.
> > 
> > No.
> > 
> > This is entirely your problem.
> > 
> > The kernel build does not work, and is not intended to work on broken setups.
> > 
> > If you have a case-insensitive filesystem, you get to keep both broken parts.
> > 
> > I actively hate case-insensitive filesystems. It's a broken model in
> > so many ways. I will not lift a finger to try to help that
> > braindamaged setup.
> > 
> > "Here's a nickel, Kid. Go buy yourself a real computer"
> > 
> >               Linus
> 
> 
> In this patch my goal is to improve Linux kernel codebase to able to
> edit/coding in any platform, in an IDE which has a modern GUI.
> 
> Chillout, i am not so stupid to compile kernel on this "braindamaged setup",
> I just like to edit the code and manage it by git commands.
> 

Then you just need to create a case-sensitive partition, no? What's the
*technical* issue of doing that? And that cannot be more challenging
than testing your kernel changes, right? So it won't raise the bar of a
potential serious kernel contributer.

> So, this is a tipical Braindamaged setup in 2024 for Generation of a half of
> Y (like me), Z and Alpha developers.
> 
> Windows or MacOS system
> - Visual Studio Code for coding
>     - Git for manage kernel source
>     - IntelliSense in coding
>     - Live coding with other developers
> 
> Linux remote server
> - Visual Studio Code remote SSH extension/connection for Linux server
>     - Sync kernel workdir with remote Ubuntu/Debian/RHEL Linux server
>     - Remote SSH compile for X86_64, ARM64 etc ...
>     - Download the build result
> 

How do you know it's "typical"? I just googled it and confirmed I'm a
Gen Y ;-) and I'm not using vscode or any IDE, a lot of Gen Y, Z and
Alpha developers I know either use Linux on their desktop/laptop or they
don't use IDEs. May my experience suffice to say it's not typical? Or is
it the case where I thought me and my friends are the whole world? ;-)

> Instead of Visual Studio Code it can be possible to use JetBrains, Eclipse
> and so on any other modern IDE. The actual limitation is only, that there is
> a filename issue in the Linux kernel source with
> "Z6.0+pooncelock+poonceLock+pombonce.litmus", why git clone is failed to
> work well in this case-insensitive OSs.

They are not "case-insensitive" OSes, they support case-sensitive
filesystems, and they support them for a reason, so just use them. With
your changes, it may be OK at clone time, but as soon as you do some
serious development involving `git bisect`, you might be very frustated
that your setup doesn't work.

So your solution is incompleted (not handling the git history), and your
goal is a bit personalized: it's only useful to people who want to
read/edit Linux code without running it and don't want to use a
case-sensitive filesystem, and that's not very persuasive. I don't think
we can accept the solution or commit to that goal.

Regards,
Boqun

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

[Szőke Benjamin]

2024. 11. 12. 2:02 keltezéssel, Boqun Feng írta:
> On Tue, Nov 12, 2024 at 12:21:51AM +0100, Sz"oke Benjamin wrote:
>> 2024. 11. 11. 23:00 keltezéssel, Linus Torvalds írta:
>>> On Mon, 11 Nov 2024 at 13:15, Sz"oke Benjamin <egyszeregy@freemail.hu> wrote:
>>>>
>>>> There is a technical issue in the Linux kernel source tree's file naming/styles
>>>> in git clone command on case-insensitive filesystem.
>>>
>>> No.
>>>
>>> This is entirely your problem.
>>>
>>> The kernel build does not work, and is not intended to work on broken setups.
>>>
>>> If you have a case-insensitive filesystem, you get to keep both broken parts.
>>>
>>> I actively hate case-insensitive filesystems. It's a broken model in
>>> so many ways. I will not lift a finger to try to help that
>>> braindamaged setup.
>>>
>>> "Here's a nickel, Kid. Go buy yourself a real computer"
>>>
>>>                Linus
>>
>>
>> In this patch my goal is to improve Linux kernel codebase to able to
>> edit/coding in any platform, in an IDE which has a modern GUI.
>>
>> Chillout, i am not so stupid to compile kernel on this "braindamaged setup",
>> I just like to edit the code and manage it by git commands.
>>
> 
> Then you just need to create a case-sensitive partition, no? What's the
> *technical* issue of doing that? And that cannot be more challenging
> than testing your kernel changes, right? So it won't raise the bar of a
> potential serious kernel contributer.
> 

It is easy to say just need a case-sensitive partition, and sure it can be 
configurable but for example on Windows, admin rights needed for it, which is 
not available in 90% for a workstation machine in an universitiy or a general 
company.


>> So, this is a tipical Braindamaged setup in 2024 for Generation of a half of
>> Y (like me), Z and Alpha developers.
>>
>> Windows or MacOS system
>> - Visual Studio Code for coding
>>      - Git for manage kernel source
>>      - IntelliSense in coding
>>      - Live coding with other developers
>>
>> Linux remote server
>> - Visual Studio Code remote SSH extension/connection for Linux server
>>      - Sync kernel workdir with remote Ubuntu/Debian/RHEL Linux server
>>      - Remote SSH compile for X86_64, ARM64 etc ...
>>      - Download the build result
>>
> 
> How do you know it's "typical"? I just googled it and confirmed I'm a
> Gen Y ;-) and I'm not using vscode or any IDE, a lot of Gen Y, Z and
> Alpha developers I know either use Linux on their desktop/laptop or they
> don't use IDEs. May my experience suffice to say it's not typical? Or is
> it the case where I thought me and my friends are the whole world? ;-)
> 
>> Instead of Visual Studio Code it can be possible to use JetBrains, Eclipse
>> and so on any other modern IDE. The actual limitation is only, that there is
>> a filename issue in the Linux kernel source with
>> "Z6.0+pooncelock+poonceLock+pombonce.litmus", why git clone is failed to
>> work well in this case-insensitive OSs.
> 
> They are not "case-insensitive" OSes, they support case-sensitive
> filesystems, and they support them for a reason, so just use them. With
> your changes, it may be OK at clone time, but as soon as you do some
> serious development involving `git bisect`, you might be very frustated
> that your setup doesn't work.
> 
> So your solution is incompleted (not handling the git history), and your
> goal is a bit personalized: it's only useful to people who want to
> read/edit Linux code without running it and don't want to use a
> case-sensitive filesystem, and that's not very persuasive. I don't think
> we can accept the solution or commit to that goal.
> 

I know the superhero operation may not possible but, i like to edit the code, i 
like to browse the code by mouse clicking easily, how possible in a limited way 
in https://elixir.bootlin.com/linux/v6.11.7/source. I like to get a well work 
IntelliSense and later Copilot AI feature.

In my use-case i do it for ARM64 embedded boards to make patches and 
modifications for my Yocto projects, it means i will run and test my kernel 
build on my target board only, which was downloaded from the remote compiler 
machine after my remote build.

As i saw that in some Youtube coding persons and cahnnels and see colleagues and 
friends, young developers more like to use IDE/GUI in Windows or MacOS for just 
coding/editing and do the basics via git, then use any SSH connection/solution 
to compile the things in remotely then test it in Qemu or a real remote 
machine/board.

In 2024 trend is for multiplatform IDEs like Eclipse, VScode and so on ... SW 
Projects also need to support the minimum possibilities to able to edit and 
manage them in multiplatform mode, otherwise this techs improvments makes no 
sense and they never take adventage of their new IDEs benefits for these 
projects in the future.

> Regards,
> Boqun

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

[Paul E. McKenney]

On Tue, Nov 12, 2024 at 11:06:05AM +0100, Szőke Benjamin wrote:
> 2024. 11. 12. 2:02 keltezéssel, Boqun Feng írta:
> > On Tue, Nov 12, 2024 at 12:21:51AM +0100, Sz"oke Benjamin wrote:
> > > 2024. 11. 11. 23:00 keltezéssel, Linus Torvalds írta:
> > > > On Mon, 11 Nov 2024 at 13:15, Sz"oke Benjamin <egyszeregy@freemail.hu> wrote:
> > > > > 
> > > > > There is a technical issue in the Linux kernel source tree's file naming/styles
> > > > > in git clone command on case-insensitive filesystem.
> > > > 
> > > > No.
> > > > 
> > > > This is entirely your problem.
> > > > 
> > > > The kernel build does not work, and is not intended to work on broken setups.
> > > > 
> > > > If you have a case-insensitive filesystem, you get to keep both broken parts.
> > > > 
> > > > I actively hate case-insensitive filesystems. It's a broken model in
> > > > so many ways. I will not lift a finger to try to help that
> > > > braindamaged setup.
> > > > 
> > > > "Here's a nickel, Kid. Go buy yourself a real computer"
> > > > 
> > > >                Linus
> > > 
> > > 
> > > In this patch my goal is to improve Linux kernel codebase to able to
> > > edit/coding in any platform, in an IDE which has a modern GUI.
> > > 
> > > Chillout, i am not so stupid to compile kernel on this "braindamaged setup",
> > > I just like to edit the code and manage it by git commands.
> > > 
> > 
> > Then you just need to create a case-sensitive partition, no? What's the
> > *technical* issue of doing that? And that cannot be more challenging
> > than testing your kernel changes, right? So it won't raise the bar of a
> > potential serious kernel contributer.
> 
> It is easy to say just need a case-sensitive partition, and sure it can be
> configurable but for example on Windows, admin rights needed for it, which
> is not available in 90% for a workstation machine in an universitiy or a
> general company.

Or, as Boqun suggested, one of these websites:

https://elixir.bootlin.com/linux/v6.11/source
https://github.com/torvalds/linux/tree/master
https://lxr.linux.no/

And quite a few more.  They have at least some of the IDE-provided
cross-referencing capabilities, though I must confess that I still use
cscope and vi.  ;-)

							Thanx, Paul

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

[Boqun Feng]

On Tue, Nov 12, 2024 at 08:43:31AM -0800, Paul E. McKenney wrote:
> On Tue, Nov 12, 2024 at 11:06:05AM +0100, Sz"oke Benjamin wrote:
> > 2024. 11. 12. 2:02 keltezéssel, Boqun Feng írta:
> > > On Tue, Nov 12, 2024 at 12:21:51AM +0100, Sz"oke Benjamin wrote:
> > > > 2024. 11. 11. 23:00 keltezéssel, Linus Torvalds írta:
> > > > > On Mon, 11 Nov 2024 at 13:15, Sz"oke Benjamin <egyszeregy@freemail.hu> wrote:
> > > > > > 
> > > > > > There is a technical issue in the Linux kernel source tree's file naming/styles
> > > > > > in git clone command on case-insensitive filesystem.
> > > > > 
> > > > > No.
> > > > > 
> > > > > This is entirely your problem.
> > > > > 
> > > > > The kernel build does not work, and is not intended to work on broken setups.
> > > > > 
> > > > > If you have a case-insensitive filesystem, you get to keep both broken parts.
> > > > > 
> > > > > I actively hate case-insensitive filesystems. It's a broken model in
> > > > > so many ways. I will not lift a finger to try to help that
> > > > > braindamaged setup.
> > > > > 
> > > > > "Here's a nickel, Kid. Go buy yourself a real computer"
> > > > > 
> > > > >                Linus
> > > > 
> > > > 
> > > > In this patch my goal is to improve Linux kernel codebase to able to
> > > > edit/coding in any platform, in an IDE which has a modern GUI.
> > > > 
> > > > Chillout, i am not so stupid to compile kernel on this "braindamaged setup",
> > > > I just like to edit the code and manage it by git commands.
> > > > 
> > > 
> > > Then you just need to create a case-sensitive partition, no? What's the
> > > *technical* issue of doing that? And that cannot be more challenging
> > > than testing your kernel changes, right? So it won't raise the bar of a
> > > potential serious kernel contributer.
> > 
> > It is easy to say just need a case-sensitive partition, and sure it can be
> > configurable but for example on Windows, admin rights needed for it, which
> > is not available in 90% for a workstation machine in an universitiy or a
> > general company.
> 
> Or, as Boqun suggested, one of these websites:
> 
> https://elixir.bootlin.com/linux/v6.11/source
> https://github.com/torvalds/linux/tree/master
> https://lxr.linux.no/
> 

I would also suggest using WSL or using GitHub codespaces or similar:

	https://github.com/codespaces

because in 2024, trend is cloud computing. ;-)

Regards,
Boqun

> And quite a few more.  They have at least some of the IDE-provided
> cross-referencing capabilities, though I must confess that I still use
> cscope and vi.  ;-)
> 
> 							Thanx, Paul

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

[Alan Stern]

On Mon, Nov 11, 2024 at 10:15:30PM +0100, Szőke Benjamin wrote:
> 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'

I support the idea of renaming one of these files.  Not to make things 
work on case-insensitive filesystems, but simply because having two 
files with rather long (and almost nonsensical) names that are identical 
aside from one single letter is an excellent way to confuse users.

Come on -- just look at the error report above.  Can you tell at a 
glance, without going through and carefully comparing the two strings 
letter-by-letter, exactly what the difference is?  Do you really think 
anybody could?

I haven't looked to see if there are any other similar examples in the 
litmus-tests directory, but if there are than they should be changed 
too.

Alan

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

[Paul E. McKenney]

On Mon, Nov 11, 2024 at 07:59:33PM -0500, Alan Stern wrote:
> On Mon, Nov 11, 2024 at 10:15:30PM +0100, Szőke Benjamin wrote:
> > 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'
> 
> I support the idea of renaming one of these files.  Not to make things 
> work on case-insensitive filesystems, but simply because having two 
> files with rather long (and almost nonsensical) names that are identical 
> aside from one single letter is an excellent way to confuse users.
> 
> Come on -- just look at the error report above.  Can you tell at a 
> glance, without going through and carefully comparing the two strings 
> letter-by-letter, exactly what the difference is?  Do you really think 
> anybody could?
> 
> I haven't looked to see if there are any other similar examples in the 
> litmus-tests directory, but if there are than they should be changed 
> too.

It does jump out at me, but even if it didn't, the usual use of tab
completion and copy/paste should make it a non-problem, not?

find . -print | tr 'A-Z' 'a-z' | sort | uniq -c | sort -k1nr | awk '{ if ($1 > 1) print }'

The output for the kernel and the github litmus repo are shown below.

							Thanx, Paul

------------------------------------------------------------------------

For the kernel:

------------------------------------------------------------------------

      2 ./include/uapi/linux/netfilter_ipv4/ipt_ecn.h
      2 ./include/uapi/linux/netfilter_ipv4/ipt_ttl.h
      2 ./include/uapi/linux/netfilter_ipv6/ip6t_hl.h
      2 ./include/uapi/linux/netfilter/xt_connmark.h
      2 ./include/uapi/linux/netfilter/xt_dscp.h
      2 ./include/uapi/linux/netfilter/xt_mark.h
      2 ./include/uapi/linux/netfilter/xt_rateest.h
      2 ./include/uapi/linux/netfilter/xt_tcpmss.h
      2 ./net/netfilter/xt_dscp.c
      2 ./net/netfilter/xt_hl.c
      2 ./net/netfilter/xt_rateest.c
      2 ./net/netfilter/xt_tcpmss.c
      2 ./tools/memory-model/litmus-tests/z6.0+pooncelock+pooncelock+pombonce.litmus

------------------------------------------------------------------------

For the github litmus repo, almost all of which are automatically
generated:

------------------------------------------------------------------------

      6 ./auto/c-lb-lrw+r-a+r-oc+r-oc.litmus
      6 ./auto/c-lb-lrw+r-a+r-oc+r-oc.litmus.out
      6 ./auto/c-lb-lrw+r-oc+r-oc+r-oc.litmus
      6 ./auto/c-lb-lrw+r-oc+r-oc+r-oc.litmus.out
      6 ./auto/lb-lrw+r-a+r-oc+r-oc.litmus.out
      6 ./auto/lb-lrw+r-oc+r-oc+r-oc.litmus.out
      5 ./auto/c-lb-lrw+r-oc+r-oc.litmus
      5 ./auto/c-lb-lrw+r-oc+r-oc.litmus.out
      5 ./auto/c-lb-lwr+r-a+r-oc+r-oc.litmus
      5 ./auto/c-lb-lwr+r-a+r-oc+r-oc.litmus.out
      5 ./auto/c-lb-lwr+r-oc+r-oc+r-oc.litmus
      5 ./auto/c-lb-lwr+r-oc+r-oc+r-oc.litmus.out
      5 ./auto/c-lb-lww+r-a+r-oc+r-oc.litmus
      5 ./auto/c-lb-lww+r-a+r-oc+r-oc.litmus.out
      5 ./auto/c-lb-lww+r-oc+r-oc+r-oc.litmus
      5 ./auto/c-lb-lww+r-oc+r-oc+r-oc.litmus.out
      5 ./auto/lb-lrw+r-oc+r-oc.litmus.out
      5 ./auto/lb-lwr+r-a+r-oc+r-oc.litmus.out
      5 ./auto/lb-lwr+r-oc+r-oc+r-oc.litmus.out
      5 ./auto/lb-lww+r-a+r-oc+r-oc.litmus.out
      5 ./auto/lb-lww+r-oc+r-oc+r-oc.litmus.out
      4 ./auto/c-lb-lwr+r-oc+r-oc.litmus
      4 ./auto/c-lb-lwr+r-oc+r-oc.litmus.out
      4 ./auto/c-lb-lww+r-oc+r-oc.litmus
      4 ./auto/c-lb-lww+r-oc+r-oc.litmus.out
      4 ./auto/lb-lwr+r-oc+r-oc.litmus.out
      4 ./auto/lb-lww+r-oc+r-oc.litmus.out
      3 ./auto/c-lb-lrw+r-a+r-a+r-oc.litmus
      3 ./auto/c-lb-lrw+r-a+r-a+r-oc.litmus.out
      3 ./auto/c-lb-lrw+r-a+r-oc.litmus
      3 ./auto/c-lb-lrw+r-a+r-oc.litmus.out
      3 ./auto/c-lb-lrw+r-oc+r-oc+r-d.litmus
      3 ./auto/c-lb-lrw+r-oc+r-oc+r-d.litmus.out
      3 ./auto/c-lb-lrw+r-oc+r-oc+r-od.litmus
      3 ./auto/c-lb-lrw+r-oc+r-oc+r-od.litmus.out
      3 ./auto/c-lb-lwr+r-a+r-a+r-oc.litmus
      3 ./auto/c-lb-lwr+r-a+r-a+r-oc.litmus.out
      3 ./auto/c-lb-lwr+r-a+r-oc.litmus
      3 ./auto/c-lb-lwr+r-a+r-oc.litmus.out
      3 ./auto/c-lb-lwr+r-oc+r-oc+r-d.litmus
      3 ./auto/c-lb-lwr+r-oc+r-oc+r-d.litmus.out
      3 ./auto/c-lb-lwr+r-oc+r-oc+r-od.litmus
      3 ./auto/c-lb-lwr+r-oc+r-oc+r-od.litmus.out
      3 ./auto/c-lb-lww+r-a+r-a+r-oc.litmus
      3 ./auto/c-lb-lww+r-a+r-a+r-oc.litmus.out
      3 ./auto/c-lb-lww+r-a+r-oc.litmus
      3 ./auto/c-lb-lww+r-a+r-oc.litmus.out
      3 ./auto/c-lb-lww+r-oc+r-oc+r-d.litmus
      3 ./auto/c-lb-lww+r-oc+r-oc+r-d.litmus.out
      3 ./auto/c-lb-lww+r-oc+r-oc+r-od.litmus
      3 ./auto/c-lb-lww+r-oc+r-oc+r-od.litmus.out
      3 ./auto/lb-lrw+r-a+r-a+r-oc.litmus.out
      3 ./auto/lb-lrw+r-a+r-oc.litmus.out
      3 ./auto/lb-lrw+r-oc+r-oc+r-d.litmus.out
      3 ./auto/lb-lrw+r-oc+r-oc+r-od.litmus.out
      3 ./auto/lb-lwr+r-a+r-a+r-oc.litmus.out
      3 ./auto/lb-lwr+r-a+r-oc.litmus.out
      3 ./auto/lb-lwr+r-oc+r-oc+r-d.litmus.out
      3 ./auto/lb-lwr+r-oc+r-oc+r-od.litmus.out
      3 ./auto/lb-lww+r-a+r-a+r-oc.litmus.out
      3 ./auto/lb-lww+r-a+r-oc.litmus.out
      3 ./auto/lb-lww+r-oc+r-oc+r-d.litmus.out
      3 ./auto/lb-lww+r-oc+r-oc+r-od.litmus.out
      2 ./auto/c-lb-lrr+r-a+ob-o+ob-o+r-oc.litmus
      2 ./auto/c-lb-lrr+r-a+ob-o+ob-o+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-a+ob-o+r-a+r-oc.litmus
      2 ./auto/c-lb-lrr+r-a+ob-o+r-a+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-a+ob-o+r-oc.litmus
      2 ./auto/c-lb-lrr+r-a+ob-o+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-a+ob-o+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrr+r-a+ob-o+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-a+r-a+ob-o+r-oc.litmus
      2 ./auto/c-lb-lrr+r-a+r-a+ob-o+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-a+r-a+r-a+r-oc.litmus
      2 ./auto/c-lb-lrr+r-a+r-a+r-a+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-a+r-a+r-oc.litmus
      2 ./auto/c-lb-lrr+r-a+r-a+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-a+r-a+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrr+r-a+r-a+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-a+r-oc.litmus
      2 ./auto/c-lb-lrr+r-a+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-a+r-oc+ob-o+r-oc.litmus
      2 ./auto/c-lb-lrr+r-a+r-oc+ob-o+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-a+r-oc+r-a+r-oc.litmus
      2 ./auto/c-lb-lrr+r-a+r-oc+r-a+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-a+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrr+r-a+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-a+r-oc+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrr+r-a+r-oc+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+ob-o+ob-o+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+ob-o+ob-o+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+ob-o+r-a+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+ob-o+r-a+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+ob-o+r-dd+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+ob-o+r-dd+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+ob-o+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+ob-o+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+ob-o+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+ob-o+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-a+ob-o+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-a+ob-o+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-a+r-a+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-a+r-a+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-a+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-a+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-a+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-a+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-dd+ob-o+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-dd+ob-o+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-dd+r-a+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-dd+r-a+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-dd+r-dd+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-dd+r-dd+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-dd+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-dd+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-dd+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-dd+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-oc+ob-o+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-oc+ob-o+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-oc+r-a+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-oc+r-a+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-oc+r-dd+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-oc+r-dd+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-dd+r-oc+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrr+r-dd+r-oc+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrr+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-oc+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrr+r-oc+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrr+r-oc+r-oc+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrr+r-oc+r-oc+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-a+ob-o+r-oc+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-a+ob-o+r-oc+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-a+ob-o+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrw+r-a+ob-o+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-a.litmus
      2 ./auto/c-lb-lrw+r-a+r-a.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-a+r-a.litmus
      2 ./auto/c-lb-lrw+r-a+r-a+r-a.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-a+r-oc+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-a+r-a+r-oc+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-a+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrw+r-a+r-a+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-d+r-oc.litmus
      2 ./auto/c-lb-lrw+r-a+r-d+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-oc+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-a+r-oc+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-oc+ob-o+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-a+r-oc+ob-o+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-oc+ob-o+r-oc.litmus
      2 ./auto/c-lb-lrw+r-a+r-oc+ob-o+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-oc+r-a+r-oc.litmus
      2 ./auto/c-lb-lrw+r-a+r-oc+r-a+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-oc+r-d.litmus
      2 ./auto/c-lb-lrw+r-a+r-oc+r-d.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-oc+r-oc+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-a+r-oc+r-oc+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-oc+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrw+r-a+r-oc+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-oc+r-od.litmus
      2 ./auto/c-lb-lrw+r-a+r-oc+r-od.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-oc+r-ov.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-od+r-oc.litmus
      2 ./auto/c-lb-lrw+r-a+r-od+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-a+r-ov+r-oc.litmus
      2 ./auto/c-lb-lrw+r-a+r-ov+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-dd+ob-o+r-oc+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-dd+ob-o+r-oc+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-dd+ob-o+r-oc+r-a.litmus
      2 ./auto/c-lb-lrw+r-dd+ob-o+r-oc+r-a.litmus.out
      2 ./auto/c-lb-lrw+r-dd+ob-o+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrw+r-dd+ob-o+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-a+r-oc+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-dd+r-a+r-oc+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-a+r-oc+r-a.litmus
      2 ./auto/c-lb-lrw+r-dd+r-a+r-oc+r-a.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-a+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrw+r-dd+r-a+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-dd+r-oc+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-dd+r-dd+r-oc+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-dd+r-oc+r-a.litmus
      2 ./auto/c-lb-lrw+r-dd+r-dd+r-oc+r-a.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-dd+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrw+r-dd+r-dd+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-oc+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-dd+r-oc+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-oc+ob-o+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-dd+r-oc+ob-o+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-oc+ob-o+r-a.litmus
      2 ./auto/c-lb-lrw+r-dd+r-oc+ob-o+r-a.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-oc+ob-o+r-oc.litmus
      2 ./auto/c-lb-lrw+r-dd+r-oc+ob-o+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-a.litmus
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-a.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-a+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-a+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-a+r-a.litmus
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-a+r-a.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-a+r-oc.litmus
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-a+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-dd+r-a.litmus
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-dd+r-a.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-dd+r-oc.litmus
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-dd+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-oc+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-oc+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-oc+r-a.litmus
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-oc+r-a.litmus.out
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrw+r-dd+r-oc+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-oc.litmus
      2 ./auto/c-lb-lrw+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-oc+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-oc+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-oc+ob-o+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-oc+ob-o+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-oc+ob-o+ob-o+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-oc+ob-o+ob-o+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-oc+ob-o+r-oc+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-oc+ob-o+r-oc+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-oc+r-d.litmus
      2 ./auto/c-lb-lrw+r-oc+r-d.litmus.out
      2 ./auto/c-lb-lrw+r-oc+r-d+r-d.litmus
      2 ./auto/c-lb-lrw+r-oc+r-d+r-d.litmus.out
      2 ./auto/c-lb-lrw+r-oc+r-d+r-od.litmus
      2 ./auto/c-lb-lrw+r-oc+r-d+r-od.litmus.out
      2 ./auto/c-lb-lrw+r-oc+r-oc+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-oc+r-oc+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-oc+r-oc+ob-o+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-oc+r-oc+ob-o+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-oc+r-oc+r-oc+ob-ob.litmus
      2 ./auto/c-lb-lrw+r-oc+r-oc+r-oc+ob-ob.litmus.out
      2 ./auto/c-lb-lrw+r-oc+r-oc+r-oc+r-oc.litmus
      2 ./auto/c-lb-lrw+r-oc+r-oc+r-oc+r-oc.litmus.out
      2 ./auto/c-lb-lrw+r-oc+r-od.litmus
      2 ./auto/c-lb-lrw+r-oc+r-od.litmus.out
      2 ./auto/c-lb-lrw+r-oc+r-od+r-d.litmus
      2 ./auto/c-lb-lrw+r-oc+r-od+r-d.litmus.out
      2 ./auto/c-lb-lrw+r-oc+r-od+r-od.litmus
      2 ./auto/c-lb-lrw+r-oc+r-od+r-od.litmus.out
      2 ./auto/c-lb-lrw+r-oc+r-ov+r-d.litmus
      2 ./auto/c-lb-lrw+r-oc+r-ov+r-d.litmus.out
      2 ./auto/c-lb-lwr+r-a+r-a.litmus
      2 ./auto/c-lb-lwr+r-a+r-a.litmus.out
      2 ./auto/c-lb-lwr+r-a+r-a+r-a.litmus
      2 ./auto/c-lb-lwr+r-a+r-a+r-a.litmus.out
      2 ./auto/c-lb-lwr+r-a+r-d+r-oc.litmus
      2 ./auto/c-lb-lwr+r-a+r-d+r-oc.litmus.out
      2 ./auto/c-lb-lwr+r-a+r-oc+r-d.litmus
      2 ./auto/c-lb-lwr+r-a+r-oc+r-d.litmus.out
      2 ./auto/c-lb-lwr+r-a+r-oc+r-od.litmus
      2 ./auto/c-lb-lwr+r-a+r-oc+r-od.litmus.out
      2 ./auto/c-lb-lwr+r-a+r-od+r-oc.litmus
      2 ./auto/c-lb-lwr+r-a+r-od+r-oc.litmus.out
      2 ./auto/c-lb-lwr+r-a+r-ov+r-oc.litmus
      2 ./auto/c-lb-lwr+r-a+r-ov+r-oc.litmus.out
      2 ./auto/c-lb-lwr+r-oc.litmus
      2 ./auto/c-lb-lwr+r-oc.litmus.out
      2 ./auto/c-lb-lwr+r-oc+r-d.litmus
      2 ./auto/c-lb-lwr+r-oc+r-d.litmus.out
      2 ./auto/c-lb-lwr+r-oc+r-d+r-d.litmus
      2 ./auto/c-lb-lwr+r-oc+r-d+r-d.litmus.out
      2 ./auto/c-lb-lwr+r-oc+r-d+r-od.litmus
      2 ./auto/c-lb-lwr+r-oc+r-d+r-od.litmus.out
      2 ./auto/c-lb-lwr+r-oc+r-od.litmus
      2 ./auto/c-lb-lwr+r-oc+r-od.litmus.out
      2 ./auto/c-lb-lwr+r-oc+r-od+r-d.litmus
      2 ./auto/c-lb-lwr+r-oc+r-od+r-d.litmus.out
      2 ./auto/c-lb-lwr+r-oc+r-od+r-od.litmus
      2 ./auto/c-lb-lwr+r-oc+r-od+r-od.litmus.out
      2 ./auto/c-lb-lwr+r-oc+r-ov+r-d.litmus
      2 ./auto/c-lb-lwr+r-oc+r-ov+r-d.litmus.out
      2 ./auto/c-lb-lww+r-a+r-a.litmus
      2 ./auto/c-lb-lww+r-a+r-a.litmus.out
      2 ./auto/c-lb-lww+r-a+r-a+r-a.litmus
      2 ./auto/c-lb-lww+r-a+r-a+r-a.litmus.out
      2 ./auto/c-lb-lww+r-a+r-d+r-oc.litmus
      2 ./auto/c-lb-lww+r-a+r-d+r-oc.litmus.out
      2 ./auto/c-lb-lww+r-a+r-oc+r-d.litmus
      2 ./auto/c-lb-lww+r-a+r-oc+r-d.litmus.out
      2 ./auto/c-lb-lww+r-a+r-oc+r-od.litmus
      2 ./auto/c-lb-lww+r-a+r-oc+r-od.litmus.out
      2 ./auto/c-lb-lww+r-a+r-od+r-oc.litmus
      2 ./auto/c-lb-lww+r-a+r-od+r-oc.litmus.out
      2 ./auto/c-lb-lww+r-a+r-ov+r-oc.litmus
      2 ./auto/c-lb-lww+r-a+r-ov+r-oc.litmus.out
      2 ./auto/c-lb-lww+r-oc.litmus
      2 ./auto/c-lb-lww+r-oc.litmus.out
      2 ./auto/c-lb-lww+r-oc+r-d.litmus
      2 ./auto/c-lb-lww+r-oc+r-d.litmus.out
      2 ./auto/c-lb-lww+r-oc+r-d+r-d.litmus
      2 ./auto/c-lb-lww+r-oc+r-d+r-d.litmus.out
      2 ./auto/c-lb-lww+r-oc+r-d+r-od.litmus
      2 ./auto/c-lb-lww+r-oc+r-d+r-od.litmus.out
      2 ./auto/c-lb-lww+r-oc+r-od.litmus
      2 ./auto/c-lb-lww+r-oc+r-od.litmus.out
      2 ./auto/c-lb-lww+r-oc+r-od+r-d.litmus
      2 ./auto/c-lb-lww+r-oc+r-od+r-d.litmus.out
      2 ./auto/c-lb-lww+r-oc+r-od+r-od.litmus
      2 ./auto/c-lb-lww+r-oc+r-od+r-od.litmus.out
      2 ./auto/c-lb-lww+r-oc+r-ov+r-d.litmus
      2 ./auto/c-lb-lww+r-oc+r-ov+r-d.litmus.out
      2 ./auto/lb-lrr+r-a+ob-o+ob-o+r-oc.litmus.out
      2 ./auto/lb-lrr+r-a+ob-o+r-a+r-oc.litmus.out
      2 ./auto/lb-lrr+r-a+ob-o+r-oc.litmus.out
      2 ./auto/lb-lrr+r-a+ob-o+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrr+r-a+r-a+ob-o+r-oc.litmus.out
      2 ./auto/lb-lrr+r-a+r-a+r-a+r-oc.litmus.out
      2 ./auto/lb-lrr+r-a+r-a+r-oc.litmus.out
      2 ./auto/lb-lrr+r-a+r-a+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrr+r-a+r-oc.litmus.out
      2 ./auto/lb-lrr+r-a+r-oc+ob-o+r-oc.litmus.out
      2 ./auto/lb-lrr+r-a+r-oc+r-a+r-oc.litmus.out
      2 ./auto/lb-lrr+r-a+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrr+r-a+r-oc+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+ob-o+ob-o+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+ob-o+r-a+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+ob-o+r-dd+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+ob-o+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+ob-o+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-a+ob-o+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-a+r-a+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-a+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-a+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-dd+ob-o+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-dd+r-a+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-dd+r-dd+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-dd+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-dd+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-oc+ob-o+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-oc+r-a+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-oc+r-dd+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrr+r-dd+r-oc+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrr+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrr+r-oc+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrr+r-oc+r-oc+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrw+r-a+ob-o+r-oc+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-a+ob-o+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrw+r-a+r-a.litmus.out
      2 ./auto/lb-lrw+r-a+r-a+r-a.litmus.out
      2 ./auto/lb-lrw+r-a+r-a+r-oc+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-a+r-a+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrw+r-a+r-d+r-oc.litmus.out
      2 ./auto/lb-lrw+r-a+r-oc+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-a+r-oc+ob-o+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-a+r-oc+ob-o+r-oc.litmus.out
      2 ./auto/lb-lrw+r-a+r-oc+r-a+r-oc.litmus.out
      2 ./auto/lb-lrw+r-a+r-oc+r-d.litmus.out
      2 ./auto/lb-lrw+r-a+r-oc+r-oc+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-a+r-oc+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrw+r-a+r-oc+r-od.litmus.out
      2 ./auto/lb-lrw+r-a+r-od+r-oc.litmus.out
      2 ./auto/lb-lrw+r-a+r-ov+r-oc.litmus.out
      2 ./auto/lb-lrw+r-dd+ob-o+r-oc+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-dd+ob-o+r-oc+r-a.litmus.out
      2 ./auto/lb-lrw+r-dd+ob-o+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrw+r-dd+r-a+r-oc+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-dd+r-a+r-oc+r-a.litmus.out
      2 ./auto/lb-lrw+r-dd+r-a+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrw+r-dd+r-dd+r-oc+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-dd+r-dd+r-oc+r-a.litmus.out
      2 ./auto/lb-lrw+r-dd+r-dd+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrw+r-dd+r-oc+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-dd+r-oc+ob-o+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-dd+r-oc+ob-o+r-a.litmus.out
      2 ./auto/lb-lrw+r-dd+r-oc+ob-o+r-oc.litmus.out
      2 ./auto/lb-lrw+r-dd+r-oc+r-a.litmus.out
      2 ./auto/lb-lrw+r-dd+r-oc+r-a+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-dd+r-oc+r-a+r-a.litmus.out
      2 ./auto/lb-lrw+r-dd+r-oc+r-a+r-oc.litmus.out
      2 ./auto/lb-lrw+r-dd+r-oc+r-dd+r-a.litmus.out
      2 ./auto/lb-lrw+r-dd+r-oc+r-dd+r-oc.litmus.out
      2 ./auto/lb-lrw+r-dd+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrw+r-dd+r-oc+r-oc+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-dd+r-oc+r-oc+r-a.litmus.out
      2 ./auto/lb-lrw+r-dd+r-oc+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrw+r-oc.litmus.out
      2 ./auto/lb-lrw+r-oc+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-oc+ob-o+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-oc+ob-o+ob-o+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-oc+ob-o+r-oc+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-oc+r-d.litmus.out
      2 ./auto/lb-lrw+r-oc+r-d+r-d.litmus.out
      2 ./auto/lb-lrw+r-oc+r-d+r-od.litmus.out
      2 ./auto/lb-lrw+r-oc+r-oc+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-oc+r-oc+ob-o+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-oc+r-oc+r-oc+ob-ob.litmus.out
      2 ./auto/lb-lrw+r-oc+r-oc+r-oc+r-oc.litmus.out
      2 ./auto/lb-lrw+r-oc+r-od.litmus.out
      2 ./auto/lb-lrw+r-oc+r-od+r-d.litmus.out
      2 ./auto/lb-lrw+r-oc+r-od+r-od.litmus.out
      2 ./auto/lb-lrw+r-oc+r-ov+r-d.litmus.out
      2 ./auto/lb-lwr+r-a+r-a.litmus.out
      2 ./auto/lb-lwr+r-a+r-a+r-a.litmus.out
      2 ./auto/lb-lwr+r-a+r-d+r-oc.litmus.out
      2 ./auto/lb-lwr+r-a+r-oc+r-d.litmus.out
      2 ./auto/lb-lwr+r-a+r-oc+r-od.litmus.out
      2 ./auto/lb-lwr+r-a+r-od+r-oc.litmus.out
      2 ./auto/lb-lwr+r-a+r-ov+r-oc.litmus.out
      2 ./auto/lb-lwr+r-oc.litmus.out
      2 ./auto/lb-lwr+r-oc+r-d.litmus.out
      2 ./auto/lb-lwr+r-oc+r-d+r-d.litmus.out
      2 ./auto/lb-lwr+r-oc+r-d+r-od.litmus.out
      2 ./auto/lb-lwr+r-oc+r-od.litmus.out
      2 ./auto/lb-lwr+r-oc+r-od+r-d.litmus.out
      2 ./auto/lb-lwr+r-oc+r-od+r-od.litmus.out
      2 ./auto/lb-lwr+r-oc+r-ov+r-d.litmus.out
      2 ./auto/lb-lww+r-a+r-a.litmus.out
      2 ./auto/lb-lww+r-a+r-a+r-a.litmus.out
      2 ./auto/lb-lww+r-a+r-d+r-oc.litmus.out
      2 ./auto/lb-lww+r-a+r-oc+r-d.litmus.out
      2 ./auto/lb-lww+r-a+r-oc+r-od.litmus.out
      2 ./auto/lb-lww+r-a+r-od+r-oc.litmus.out
      2 ./auto/lb-lww+r-a+r-ov+r-oc.litmus.out
      2 ./auto/lb-lww+r-oc.litmus.out
      2 ./auto/lb-lww+r-oc+r-d.litmus.out
      2 ./auto/lb-lww+r-oc+r-d+r-d.litmus.out
      2 ./auto/lb-lww+r-oc+r-d+r-od.litmus.out
      2 ./auto/lb-lww+r-oc+r-od.litmus.out
      2 ./auto/lb-lww+r-oc+r-od+r-d.litmus.out
      2 ./auto/lb-lww+r-oc+r-od+r-od.litmus.out
      2 ./auto/lb-lww+r-oc+r-ov+r-d.litmus.out
      2 ./rculitmusgen/lisa2c.sh

------------------------------------------------------------------------

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

[Alan Stern]

On Mon, Nov 11, 2024 at 08:20:05PM -0800, Paul E. McKenney wrote:
> On Mon, Nov 11, 2024 at 07:59:33PM -0500, Alan Stern wrote:
> > On Mon, Nov 11, 2024 at 10:15:30PM +0100, Szőke Benjamin wrote:
> > > 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'
> > 
> > I support the idea of renaming one of these files.  Not to make things 
> > work on case-insensitive filesystems, but simply because having two 
> > files with rather long (and almost nonsensical) names that are identical 
> > aside from one single letter is an excellent way to confuse users.
> > 
> > Come on -- just look at the error report above.  Can you tell at a 
> > glance, without going through and carefully comparing the two strings 
> > letter-by-letter, exactly what the difference is?  Do you really think 
> > anybody could?
> > 
> > I haven't looked to see if there are any other similar examples in the 
> > litmus-tests directory, but if there are than they should be changed 
> > too.
> 
> It does jump out at me,

Maybe this means you've spent too much of your life concentrating on 
these files!  :-)

>  but even if it didn't, the usual use of tab
> completion and copy/paste should make it a non-problem, not?

Those things help when people want to type in a filename.  They do not 
help when people are trying to read the filenames, figure out what the 
difference between them is, compare a name mentioned in one place to a 
name mentioned in another place, or understand how the names are related 
to the file contents.

> find . -print | tr 'A-Z' 'a-z' | sort | uniq -c | sort -k1nr | awk '{ if ($1 > 1) print }'
> 
> The output for the kernel and the github litmus repo are shown below.
> 
> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> For the kernel:
> 
> ------------------------------------------------------------------------
> 
>       2 ./include/uapi/linux/netfilter_ipv4/ipt_ecn.h
>       2 ./include/uapi/linux/netfilter_ipv4/ipt_ttl.h
>       2 ./include/uapi/linux/netfilter_ipv6/ip6t_hl.h
>       2 ./include/uapi/linux/netfilter/xt_connmark.h
>       2 ./include/uapi/linux/netfilter/xt_dscp.h
>       2 ./include/uapi/linux/netfilter/xt_mark.h
>       2 ./include/uapi/linux/netfilter/xt_rateest.h
>       2 ./include/uapi/linux/netfilter/xt_tcpmss.h
>       2 ./net/netfilter/xt_dscp.c
>       2 ./net/netfilter/xt_hl.c
>       2 ./net/netfilter/xt_rateest.c
>       2 ./net/netfilter/xt_tcpmss.c

Those are all fine.  The filenames are nice and short, and the case 
differences really do stand out because they affect entire words, not 
just a single letter in the middle of a long string of letters.

>       2 ./tools/memory-model/litmus-tests/z6.0+pooncelock+pooncelock+pombonce.litmus

This stands for the files we're talking about, right?  It needs help.

> ------------------------------------------------------------------------
> 
> For the github litmus repo, almost all of which are automatically
> generated:

I'm not so concerned about these.  A litmus test repo isn't in the same 
category as a kernel source directory.  Maybe it wouldn't hurt to make 
some of them more distinguishable (I haven't looked at the original 
names to tell), but they're not our problem here and now.

Alan

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

[Paul E. McKenney]

On Tue, Nov 12, 2024 at 10:35:25AM -0500, Alan Stern wrote:
> On Mon, Nov 11, 2024 at 08:20:05PM -0800, Paul E. McKenney wrote:
> > On Mon, Nov 11, 2024 at 07:59:33PM -0500, Alan Stern wrote:
> > > On Mon, Nov 11, 2024 at 10:15:30PM +0100, Szőke Benjamin wrote:
> > > > 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'
> > > 
> > > I support the idea of renaming one of these files.  Not to make things 
> > > work on case-insensitive filesystems, but simply because having two 
> > > files with rather long (and almost nonsensical) names that are identical 
> > > aside from one single letter is an excellent way to confuse users.
> > > 
> > > Come on -- just look at the error report above.  Can you tell at a 
> > > glance, without going through and carefully comparing the two strings 
> > > letter-by-letter, exactly what the difference is?  Do you really think 
> > > anybody could?
> > > 
> > > I haven't looked to see if there are any other similar examples in the 
> > > litmus-tests directory, but if there are than they should be changed 
> > > too.
> > 
> > It does jump out at me,
> 
> Maybe this means you've spent too much of your life concentrating on 
> these files!  :-)

It is all too easy to argue that I have spent too much of my life
concentrating on files in general, not just these.  ;-)

> >  but even if it didn't, the usual use of tab
> > completion and copy/paste should make it a non-problem, not?
> 
> Those things help when people want to type in a filename.  They do not 
> help when people are trying to read the filenames, figure out what the 
> difference between them is, compare a name mentioned in one place to a 
> name mentioned in another place, or understand how the names are related 
> to the file contents.

All true, but beyond a certain point, we can solicit help from our
friendly nearby computer.  For example, create a temporary directory,
use "touch" to create the two names (based on copy and paste) in that
temporary directory, then let bash tab completion help us out.

But you make a good point later...

> > find . -print | tr 'A-Z' 'a-z' | sort | uniq -c | sort -k1nr | awk '{ if ($1 > 1) print }'
> > 
> > The output for the kernel and the github litmus repo are shown below.
> > 
> > 							Thanx, Paul
> > 
> > ------------------------------------------------------------------------
> > 
> > For the kernel:
> > 
> > ------------------------------------------------------------------------
> > 
> >       2 ./include/uapi/linux/netfilter_ipv4/ipt_ecn.h
> >       2 ./include/uapi/linux/netfilter_ipv4/ipt_ttl.h
> >       2 ./include/uapi/linux/netfilter_ipv6/ip6t_hl.h
> >       2 ./include/uapi/linux/netfilter/xt_connmark.h
> >       2 ./include/uapi/linux/netfilter/xt_dscp.h
> >       2 ./include/uapi/linux/netfilter/xt_mark.h
> >       2 ./include/uapi/linux/netfilter/xt_rateest.h
> >       2 ./include/uapi/linux/netfilter/xt_tcpmss.h
> >       2 ./net/netfilter/xt_dscp.c
> >       2 ./net/netfilter/xt_hl.c
> >       2 ./net/netfilter/xt_rateest.c
> >       2 ./net/netfilter/xt_tcpmss.c
> 
> Those are all fine.  The filenames are nice and short, and the case 
> differences really do stand out because they affect entire words, not 
> just a single letter in the middle of a long string of letters.
> 
> >       2 ./tools/memory-model/litmus-tests/z6.0+pooncelock+pooncelock+pombonce.litmus
> 
> This stands for the files we're talking about, right?  It needs help.

We do have a rule for the filenames in that directory that most of
them follow (I am looking at *you*, "dep+plain.litmus"!).  So we have
a few options:

1.	Status quo.  (How boring!!!)

2.	Come up with a better rule mapping the litmus-test file
	contents to the filename, and rename things to follow that rule.
	(Holy bikeshedding, Batman!)

3.	Keep it simple and keep the current rule, but make the
	combination of spin_lock() and smp_mb__after_spinlock()
	have a greater Hamming distance from "lock".  Szőke's
	patch changed only one of the filenames containing "Lock".
	(Bikeshedding, but narrower scope.)

4.	One of the above, but bring the litmus tests not following
	the rule into compliance.

5.	Give up on the idea of the name reflecting the contents of the
	file, and just number them or something.  (More bikeshedding
	and a different form of confusion.)

6.	#5, but accompanied by some tool or script that allows easy
	searching of the litmus tests by pattern of interaction.
	(Easy for *me* to say!)

7.	Something else entirely.

Thoughts?

> > ------------------------------------------------------------------------
> > 
> > For the github litmus repo, almost all of which are automatically
> > generated:
> 
> I'm not so concerned about these.  A litmus test repo isn't in the same 
> category as a kernel source directory.  Maybe it wouldn't hurt to make 
> some of them more distinguishable (I haven't looked at the original 
> names to tell), but they're not our problem here and now.

Plus any changes would require corresponding changes to the scripts
generating them, which I currently lack both enthusiasm and time for.  ;-)

							Thanx, Paul

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

[Alan Stern]

On Tue, Nov 12, 2024 at 10:26:37AM -0800, Paul E. McKenney wrote:
> We do have a rule for the filenames in that directory that most of
> them follow (I am looking at *you*, "dep+plain.litmus"!).  So we have
> a few options:
> 
> 1.	Status quo.  (How boring!!!)
> 
> 2.	Come up with a better rule mapping the litmus-test file
> 	contents to the filename, and rename things to follow that rule.
> 	(Holy bikeshedding, Batman!)
> 
> 3.	Keep it simple and keep the current rule, but make the
> 	combination of spin_lock() and smp_mb__after_spinlock()
> 	have a greater Hamming distance from "lock".  Szőke's
> 	patch changed only one of the filenames containing "Lock".
> 	(Bikeshedding, but narrower scope.)
> 
> 4.	One of the above, but bring the litmus tests not following
> 	the rule into compliance.
> 
> 5.	Give up on the idea of the name reflecting the contents of the
> 	file, and just number them or something.  (More bikeshedding
> 	and a different form of confusion.)
> 
> 6.	#5, but accompanied by some tool or script that allows easy
> 	searching of the litmus tests by pattern of interaction.
> 	(Easy for *me* to say!)
> 
> 7.	Something else entirely.
> 
> Thoughts?

Thumbs up for 3.

Alan

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

[Paul E. McKenney]

On Tue, Nov 12, 2024 at 03:20:00PM -0500, Alan Stern wrote:
> On Tue, Nov 12, 2024 at 10:26:37AM -0800, Paul E. McKenney wrote:
> > We do have a rule for the filenames in that directory that most of
> > them follow (I am looking at *you*, "dep+plain.litmus"!).  So we have
> > a few options:
> > 
> > 1.	Status quo.  (How boring!!!)
> > 
> > 2.	Come up with a better rule mapping the litmus-test file
> > 	contents to the filename, and rename things to follow that rule.
> > 	(Holy bikeshedding, Batman!)
> > 
> > 3.	Keep it simple and keep the current rule, but make the
> > 	combination of spin_lock() and smp_mb__after_spinlock()
> > 	have a greater Hamming distance from "lock".  Szőke's
> > 	patch changed only one of the filenames containing "Lock".
> > 	(Bikeshedding, but narrower scope.)
> > 
> > 4.	One of the above, but bring the litmus tests not following
> > 	the rule into compliance.
> > 
> > 5.	Give up on the idea of the name reflecting the contents of the
> > 	file, and just number them or something.  (More bikeshedding
> > 	and a different form of confusion.)
> > 
> > 6.	#5, but accompanied by some tool or script that allows easy
> > 	searching of the litmus tests by pattern of interaction.
> > 	(Easy for *me* to say!)
> > 
> > 7.	Something else entirely.
> > 
> > Thoughts?
> 
> Thumbs up for 3.

Very good!  Any nominations for the lucky replacement for "Lock"?

							Thanx, Paul

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

[Szőke Benjamin]

2024. 11. 12. 22:53 keltezéssel, Paul E. McKenney írta:
> On Tue, Nov 12, 2024 at 03:20:00PM -0500, Alan Stern wrote:
>> On Tue, Nov 12, 2024 at 10:26:37AM -0800, Paul E. McKenney wrote:
>>> We do have a rule for the filenames in that directory that most of
>>> them follow (I am looking at *you*, "dep+plain.litmus"!).  So we have
>>> a few options:
>>>
>>> 1.	Status quo.  (How boring!!!)
>>>
>>> 2.	Come up with a better rule mapping the litmus-test file
>>> 	contents to the filename, and rename things to follow that rule.
>>> 	(Holy bikeshedding, Batman!)
>>>
>>> 3.	Keep it simple and keep the current rule, but make the
>>> 	combination of spin_lock() and smp_mb__after_spinlock()
>>> 	have a greater Hamming distance from "lock".  Szőke's
>>> 	patch changed only one of the filenames containing "Lock".
>>> 	(Bikeshedding, but narrower scope.)
>>>
>>> 4.	One of the above, but bring the litmus tests not following
>>> 	the rule into compliance.
>>>
>>> 5.	Give up on the idea of the name reflecting the contents of the
>>> 	file, and just number them or something.  (More bikeshedding
>>> 	and a different form of confusion.)
>>>
>>> 6.	#5, but accompanied by some tool or script that allows easy
>>> 	searching of the litmus tests by pattern of interaction.
>>> 	(Easy for *me* to say!)
>>>
>>> 7.	Something else entirely.
>>>
>>> Thoughts?
>>
>> Thumbs up for 3.
> 
> Very good!  Any nominations for the lucky replacement for "Lock"?
> 
> 							Thanx, Paul

Subject: [PATCH] tools/memory-model: Fix litmus-tests's file names.
Makes a greater Hamming distance for name of Z6.0+pooncelock* files.
https://lore.kernel.org/lkml/20241209150044.766-1-egyszeregy@freemail.hu/