From: Boqun Feng <boqun.feng@gmail.com>
To: "Sz\"oke Benjamin" <egyszeregy@freemail.hu>
Cc: paulmck@kernel.org, stern@rowland.harvard.edu,
parri.andrea@gmail.com, will@kernel.org, peterz@infradead.org,
npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk,
luc.maranget@inria.fr, akiyks@gmail.com, dlustig@nvidia.com,
joel@joelfernandes.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, lkmm@lists.linux.dev,
torvalds@linux-foundation.org
Subject: Re: [PATCH] tools/memory-model: Fix litmus-tests's file names for case-insensitive filesystem.
Date: Mon, 11 Nov 2024 13:23:41 -0800 [thread overview]
Message-ID: <ZzJ13eM2SNNB3fl7@tardis.local> (raw)
In-Reply-To: <a42da186-195c-40af-b4ee-0eaf6672cf2c@freemail.hu>
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.
next prev parent reply other threads:[~2024-11-11 21:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-11 16:42 [PATCH] tools/memory-model: Fix litmus-tests's file names for case-insensitive filesystem egyszeregy
2024-11-11 16:54 ` Paul E. McKenney
2024-11-11 18:52 ` Szőke Benjamin
2024-11-11 19:22 ` Paul E. McKenney
2024-11-11 19:56 ` Szőke Benjamin
2024-11-11 20:29 ` Paul E. McKenney
2024-11-11 21:15 ` Szőke Benjamin
2024-11-11 21:23 ` Boqun Feng [this message]
2024-11-11 21:39 ` Szőke Benjamin
2024-11-11 21:44 ` Boqun Feng
2024-11-11 21:52 ` Paul E. McKenney
2024-11-11 22:00 ` Linus Torvalds
2024-11-11 23:21 ` Szőke Benjamin
2024-11-12 1:02 ` Boqun Feng
2024-11-12 10:06 ` Szőke Benjamin
2024-11-12 16:43 ` Paul E. McKenney
2024-11-12 16:56 ` Boqun Feng
2024-11-12 0:59 ` Alan Stern
2024-11-12 4:20 ` Paul E. McKenney
2024-11-12 15:35 ` Alan Stern
2024-11-12 18:26 ` Paul E. McKenney
2024-11-12 20:20 ` Alan Stern
2024-11-12 21:53 ` Paul E. McKenney
2024-12-12 23:09 ` Szőke Benjamin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZzJ13eM2SNNB3fl7@tardis.local \
--to=boqun.feng@gmail.com \
--cc=akiyks@gmail.com \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=egyszeregy@freemail.hu \
--cc=j.alglave@ucl.ac.uk \
--cc=joel@joelfernandes.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkmm@lists.linux.dev \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).