Message-ID: <de5485b8-6d88-46f6-b982-cdfb3cf80a13@paulmck-laptop>
Date: Tue, 12 Nov 2024 10:26:37 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Szőke Benjamin <egyszeregy@...email.hu>,
	parri.andrea@...il.com, will@...nel.org, peterz@...radead.org,
	boqun.feng@...il.com, npiggin@...il.com, dhowells@...hat.com,
	j.alglave@....ac.uk, luc.maranget@...ia.fr, akiyks@...il.com,
	dlustig@...dia.com, joel@...lfernandes.org,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	lkmm@...ts.linux.dev, torvalds@...ux-foundation.org
Subject: Re: [PATCH] tools/memory-model: Fix litmus-tests's file names for
 case-insensitive filesystem.

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

Powered by blists - more mailing lists