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@xxxxxxxxxxx wrote:
From: Benjamin Sz"oke <egyszeregy@xxxxxxxxxxx>
The goal is to fix Linux repository for case-insensitive filesystem,
to able to clone it and editable on any operating systems.
Rename "Z6.0+pooncelock+poonceLock+pombonce.litmus" to
"Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus".
Signed-off-by: Benjamin Sz"oke <egyszeregy@xxxxxxxxxxx>
Ummm... Really?
Just out of curiosity, which operating-system/filesystem combination are
you working with? And why not instead fix that combination to handle
mixed case?
Thanx, Paul
Windows and also MacOS is not case sensitive by default. My goal is to
improve Linux kernel source-tree, to able to develop it in any operating
systems for example via Visual Studio Code extensions/IntelliSense feature
or any similar IDE which is usable in any OS.
Why not simply enable case sensitivity on the file tree in which you
are processing Linux-kernel source code?
For MacOS: https://discussions.apple.com/thread/251191099?sortBy=rank
For Windows: https://learn.microsoft.com/en-us/windows/wsl/case-sensitivity
In some cases it might work better to simply run a Linux VM on top of
Windows or MacOS.
They tell me that webservers already do this, so why not also for
Linux-kernel source code?
Why we not solve it as simple as it can in the source code of the Linux
kernel with renaming? It would be more robust and more durable to fix this
issue/inconviniant in the source as an overal complete solution. Nobody like
to figth with configuraition hell of Windows and MacOS, or build up a
diskspace consumer Virtual Linux with crappy GUI capapilities for coding big
things.
Young developers will never be willing to join and contributing in Linux
kernel in the future if Linux kernel code is not editable in a high-quality,
easy-to-use IDE for, which is usable in any OS.
There are a great number of software projects out there that use mixed
case. Therefore, can an IDE that does not gracefully handle mixed case
really be said to be either high quality or easy to use?
In other words, you have the option of making the IDE handle this.
Need to improve this kind of things and simplify/modernize developing or
never will be solved the following issues:
https://www.youtube.com/watch?v=lJLw94pAcBY
Sorry, but that video does not support your point. In fact, the presenter
clearly states that this sort of tooling issue is not a real problem
for the Linux kernel near the middle of that video.
Thanx, Paul
There were some accepted patches which aim this same goal.
https://gitlab.freedesktop.org/drm/kernel/-/commit/231bb9b4c42398db3114c087ba39ba00c4b7ac2c
https://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/commit/?h=for-curr&id=8bf275d61925cff45568438c73f114e46237ad7e
Fair enough, as it is the maintainer's choice. Which means that
their accepting these case-sensitivity changes does not require other
maintainers to do so.
Thanx, Paul
---
tools/memory-model/Documentation/locking.txt | 2 +-
tools/memory-model/Documentation/recipes.txt | 2 +-
tools/memory-model/litmus-tests/README | 2 +-
...> Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus} | 0
4 files changed, 3 insertions(+), 3 deletions(-)
rename tools/memory-model/litmus-tests/{Z6.0+pooncelock+poonceLock+pombonce.litmus => Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus} (100%)
diff --git a/tools/memory-model/Documentation/locking.txt b/tools/memory-model/Documentation/locking.txt
index 65c898c64a93..42bc3efe2015 100644
--- a/tools/memory-model/Documentation/locking.txt
+++ b/tools/memory-model/Documentation/locking.txt
@@ -184,7 +184,7 @@ ordering properties.
Ordering can be extended to CPUs not holding the lock by careful use
of smp_mb__after_spinlock():
- /* See Z6.0+pooncelock+poonceLock+pombonce.litmus. */
+ /* See Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus. */
void CPU0(void)
{
spin_lock(&mylock);
diff --git a/tools/memory-model/Documentation/recipes.txt b/tools/memory-model/Documentation/recipes.txt
index 03f58b11c252..35996eb1b690 100644
--- a/tools/memory-model/Documentation/recipes.txt
+++ b/tools/memory-model/Documentation/recipes.txt
@@ -159,7 +159,7 @@ lock's ordering properties.
Ordering can be extended to CPUs not holding the lock by careful use
of smp_mb__after_spinlock():
- /* See Z6.0+pooncelock+poonceLock+pombonce.litmus. */
+ /* See Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus. */
void CPU0(void)
{
spin_lock(&mylock);
diff --git a/tools/memory-model/litmus-tests/README b/tools/memory-model/litmus-tests/README
index d311a0ff1ae6..e3d451346400 100644
--- a/tools/memory-model/litmus-tests/README
+++ b/tools/memory-model/litmus-tests/README
@@ -149,7 +149,7 @@ Z6.0+pooncelock+pooncelock+pombonce.litmus
spin_lock() sufficient to make ordering apparent to accesses
by a process not holding the lock?
-Z6.0+pooncelock+poonceLock+pombonce.litmus
+Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus
As above, but with smp_mb__after_spinlock() immediately
following the spin_lock().
diff --git a/tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+pombonce.litmus b/tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus
similarity index 100%
rename from tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+pombonce.litmus
rename to tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+after_spinlock+pombonce.litmus
--
2.47.0.windows.2
There is a technical issue in the Linux kernel source tree's file
naming/styles in git clone command on case-insensitive filesystem.
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:
'tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+pombonce.litmus'
'tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus'
As you a maintainer, what is your suggestion to fix it in the source code of
the Linux kernel? Please send a real technical suggestion not just how could
it be done in an other way (which is out of the scope now).
Is my renaming patch correct to solve it? Question is what is the most
No, because once you do a checkout to a commit that previous to your
changes, things are going to break again. The real "issue" is git use
case-sensitive file names, so unless you can rewrite the whole history,
your "solution" goes nowhere.
Regards,
Boqun
effective and proper fix/solution which can be commited into the Linux
kernel repo to fix it.
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.
