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
