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.
