Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

Mauro Carvalho Chehab
2020-07-09T11:11:42Z

Em Mon, 06 Jul 2020 06:30:01 -0700
Joe Perches <joe@perches.com> escreveu:

> On Mon, 2020-07-06 at 09:04 -0400, Matthew Wilcox wrote:
> > On Mon, Jul 6, 2020 at 8:59 AM Joe Perches <joe@perches.com> wrote:
> > > On Mon, 2020-07-06 at 08:51 -0400, Matthew Wilcox wrote:
> > > > In terms of number of lines of code using the word, it's only seventh
> > > > in drivers/:
> > > >
> > > > $ for i in drivers/*; do c=$(find $i -type f |xargs grep slave |wc
> > > > -l); echo "$c $i"; done |sort -rn |head
> > > > 5218 drivers/net
> > > > 1341 drivers/dma
> > > > 988 drivers/i2c
> > > > 695 drivers/gpu
> > > > 666 drivers/soundwire
> > > > 665 drivers/spi
> > > > 559 drivers/w1
> > > > 461 drivers/infiniband
> > > > 389 drivers/media
> > > > 301 drivers/scsi
> > >
> > > I get rather different and much lower numbers
> > >
> > > $ git grep -i -w slave drivers | \
> > > cut -f1,2 -d/ | uniq -c | sort -rn | head -20 | cat -n
> >
> > That's because you're using grep -w which excludes, for example,
> > slave_configure in drivers/scsi.
>
> upper/lower case uses too... (anyway, there are a lot)
>
> $ git grep -i -w -P '\w*slave\w*' drivers | \
> cut -f1,2 -d/ | uniq -c | sort -rn | head -20 | cat -n
> 1 5683 drivers/net
> 2 2118 drivers/gpu
> 3 1807 drivers/dma
> 4 1389 drivers/i2c
> 5 866 drivers/interconnect
> 6 835 drivers/soundwire
> 7 821 drivers/spi
> 8 698 drivers/w1
> 9 508 drivers/media
> 10 481 drivers/infiniband
> 11 440 drivers/ata
> 12 317 drivers/scsi
> 13 267 drivers/fsi
> 14 240 drivers/tty
> 15 225 drivers/vme
> 16 223 drivers/staging
> 17 157 drivers/mmc
> 18 155 drivers/usb
> 19 141 drivers/video
> 20 140 drivers/char

It sounds that, as soon after this patch gets merged, the mailing lists
will be flooded by lots of patches replacing such terms with something
else :-(

Doing a quick look at the media subsystem, it sounds that most terms
come from I2C master/slave and DiSEqC terminology, as defined by their
specs (and the others seem to be derived from some hardware vendor
specific terminology).

As they're all supported by the current specs, if one would want
to replace them, it should first ensure that the supporting specs
should be using a different terminology, as otherwise replacing
them would just make harder for anyone trying to understand the
code.

Thanks,
Mauro