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

[Archie Pusaka]

Hi Emil,

On Tue, 25 May 2021 at 20:19, Emil Lenngren <emil.lenngren@xxxxxxxxx> wrote:
>
> Hi Archie,
>
> Den tis 25 maj 2021 kl 12:46 skrev Archie Pusaka <apusaka@xxxxxxxxxx>:
> >
> > From: Archie Pusaka <apusaka@xxxxxxxxxxxx>
> >
> > 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?

> 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.

Cheers,
Archie