Re: [PATCH 00/12] Bluetooth: use inclusive language

From
Emil Lenngren <hidden>
Date
2021-05-25 15:18:44
Also in
linux-bluetooth, lkml
Reply to
Archie Pusaka, 2021-05-25
Hi Archie,

Den tis 25 maj 2021 kl 16:34 skrev Archie Pusaka [off-list ref]:
Hi Emil,

On Tue, 25 May 2021 at 20:19, Emil Lenngren [off-list ref] wrote:
quoted
Hi Archie,

Den tis 25 maj 2021 kl 12:46 skrev Archie Pusaka [off-list ref]:
quoted
From: Archie Pusaka <redacted>

Hi linux-bluetooth maintainers,

This series contains inclusive language patches, to promote usage of
central, peripheral, reject list, and accept list. I tried to divide
the change to several smaller patches to ease downstreamers to make
gradual change.

There are still three occurences in debugfs (patch 09/12) in which the
original less inclusive terms is still left as-is since it is a
file name, and I afraid replacing them will cause instability to
other systems depending on that file name.


Archie Pusaka (12):
  Bluetooth: use inclusive language in HCI role
  Bluetooth: use inclusive language in hci_core.h
  Bluetooth: use inclusive language to describe CPB
  Bluetooth: use inclusive language in HCI LE features
  Bluetooth: use inclusive language in L2CAP
  Bluetooth: use inclusive language in RFCOMM
  Bluetooth: use inclusive language when tracking connections
  Bluetooth: use inclusive language in SMP
  Bluetooth: use inclusive language in debugfs
  Bluetooth: use inclusive language when filtering devices out
  Bluetooth: use inclusive language when filtering devices in
  Bluetooth: use inclusive language in comments

 include/net/bluetooth/hci.h      |  98 +++++++++++++-------------
 include/net/bluetooth/hci_core.h |  22 +++---
 include/net/bluetooth/l2cap.h    |   2 +-
 include/net/bluetooth/mgmt.h     |   2 +-
 include/net/bluetooth/rfcomm.h   |   2 +-
 net/bluetooth/amp.c              |   2 +-
 net/bluetooth/hci_conn.c         |  32 ++++-----
 net/bluetooth/hci_core.c         |  46 ++++++-------
 net/bluetooth/hci_debugfs.c      |  20 +++---
 net/bluetooth/hci_event.c        | 114 +++++++++++++++----------------
 net/bluetooth/hci_request.c      | 106 ++++++++++++++--------------
 net/bluetooth/hci_sock.c         |  12 ++--
 net/bluetooth/hidp/core.c        |   2 +-
 net/bluetooth/l2cap_core.c       |  16 ++---
 net/bluetooth/l2cap_sock.c       |   4 +-
 net/bluetooth/mgmt.c             |  36 +++++-----
 net/bluetooth/rfcomm/sock.c      |   4 +-
 net/bluetooth/smp.c              |  86 +++++++++++------------
 net/bluetooth/smp.h              |   6 +-
 19 files changed, 309 insertions(+), 303 deletions(-)

--
2.31.1.818.g46aad6cb9e-goog
Interesting move and good initiative!

In my opinion however, shouldn't we wait until Bluetooth SIG changes
the naming in the specification itself first (or rather push them to
make the changes in the first place)? If they are about to change
names, it would be good to make sure we end up with the same word
choices so that we don't call one thing "le peripheral initiated
feature exchange" while the standard calls it "le follower initiated
feature exchange" or similar. Using different terminology than what's
specified by the standard could easily end up in confusion I guess,
and even more if different stacks invented their own alternative
terminology.
So far the Bluetooth SIG has only published an "Appropriate Language
Mapping Table" (https://specificationrefs.bluetooth.com/language-mapping/Appropriate_Language_Mapping_Table.pdf).
It doesn't look like it's finalized, but it's enough to get started.
Hopefully someone in the community can help to push the changes to the
spec?
quoted
In any case, I'm for example not sure if central/peripheral are the
best words to use, since those are tied to a specific higher level
profile (Generic Access Profile) and those words are not mentioned at
all in the spec outside that context. The SMP chapter for example uses
the terminology "initiator" and "responder", so maybe those are better
word choices, at least in SMP.
Thanks, you are correct about that. I didn't read the spec thoroughly
and just did a simple replacement. I shall incorporate your suggestion
if this set of patches is greenlighted.
Yeah that document really seems to be "in progress". As you can see,
they have replaced Srand (slave random, used in SMP) by LP_RAND_R
(legacy pairing, responder random number) so it seems they thought in
the same way as I did, at least for SMP. And indeed, as in your patch
they seem to prefer "central" and "peripheral", even outside GAP.

So my guess is that we could rename at least the terms that are in
that list right now, but probably wait with terms not yet present in
the list. Or patch everything at once when Bluetooth SIG has finished
the naming. (Note that I'm not a maintainer so someone else will need
to decide)

/Emil
Thread (21 messages) 21 messages, 3 authors, last reply 2021-05-31
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help