| Message ID | 20210525102941.3958649-1-apusaka@google.com |
|---|---|
| Headers | show |
| Series | Bluetooth: use inclusive language | expand |
Hi Archie, Den tis 25 maj 2021 kl 12:46 skrev Archie Pusaka <apusaka@google.com>: > > From: Archie Pusaka <apusaka@chromium.org> > > 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. 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. /Emil
Hi Emil, On Tue, 25 May 2021 at 20:19, Emil Lenngren <emil.lenngren@gmail.com> wrote: > > Hi Archie, > > Den tis 25 maj 2021 kl 12:46 skrev Archie Pusaka <apusaka@google.com>: > > > > From: Archie Pusaka <apusaka@chromium.org> > > > > 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
Hi Archie, Den tis 25 maj 2021 kl 16:34 skrev Archie Pusaka <apusaka@google.com>: > > Hi Emil, > > On Tue, 25 May 2021 at 20:19, Emil Lenngren <emil.lenngren@gmail.com> wrote: > > > > Hi Archie, > > > > Den tis 25 maj 2021 kl 12:46 skrev Archie Pusaka <apusaka@google.com>: > > > > > > From: Archie Pusaka <apusaka@chromium.org> > > > > > > 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. > 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
Hi Archie, > Use "central" and "peripheral". > > Signed-off-by: Archie Pusaka <apusaka@chromium.org> > Reviewed-by: Miao-chen Chou <mcchou@chromium.org> > > --- > > include/net/bluetooth/rfcomm.h | 2 +- > net/bluetooth/rfcomm/sock.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h > index 99d26879b02a..6472ec0053b9 100644 > --- a/include/net/bluetooth/rfcomm.h > +++ b/include/net/bluetooth/rfcomm.h > @@ -290,7 +290,7 @@ struct rfcomm_conninfo { > }; > > #define RFCOMM_LM 0x03 > -#define RFCOMM_LM_MASTER 0x0001 > +#define RFCOMM_LM_CENTRAL 0x0001 > #define RFCOMM_LM_AUTH 0x0002 > #define RFCOMM_LM_ENCRYPT 0x0004 > #define RFCOMM_LM_TRUSTED 0x0008 I am not planning to accept this change any time soon since this is also in the libbluetooth API. Regards Marcel
Hi Archie, > Use "reject list". I really think you need to write a bit of a commit message for these patches. > > Signed-off-by: Archie Pusaka <apusaka@chromium.org> > Reviewed-by: Miao-chen Chou <mcchou@chromium.org> > > --- > > include/net/bluetooth/hci_core.h | 2 +- > net/bluetooth/hci_core.c | 4 ++-- > net/bluetooth/hci_debugfs.c | 2 +- > net/bluetooth/hci_event.c | 6 +++--- > net/bluetooth/hci_sock.c | 12 ++++++------ > net/bluetooth/l2cap_core.c | 4 ++-- > net/bluetooth/mgmt.c | 4 ++-- > 7 files changed, 17 insertions(+), 17 deletions(-) > > diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h > index cfe2ada49ca2..9c8cdc4fe3c5 100644 > --- a/include/net/bluetooth/hci_core.h > +++ b/include/net/bluetooth/hci_core.h > @@ -522,7 +522,7 @@ struct hci_dev { > struct hci_conn_hash conn_hash; > > struct list_head mgmt_pending; > - struct list_head blacklist; > + struct list_head reject_list; > struct list_head whitelist; Can we change these two in the same patch please. Regards Marcel
Hi Marcel, Thanks for the reply. I have sent v2 which omits this patch. Please take a look. I am not familiar with the libbluetooth API. Could you tell me more about it? Beside this and the L2CAP change, are there any other terms replacement which can't be accepted due to the libbluetooth API? Cheers, Archie On Wed, 26 May 2021 at 23:07, Marcel Holtmann <marcel@holtmann.org> wrote: > > Hi Archie, > > > Use "central" and "peripheral". > > > > Signed-off-by: Archie Pusaka <apusaka@chromium.org> > > Reviewed-by: Miao-chen Chou <mcchou@chromium.org> > > > > --- > > > > include/net/bluetooth/rfcomm.h | 2 +- > > net/bluetooth/rfcomm/sock.c | 4 ++-- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h > > index 99d26879b02a..6472ec0053b9 100644 > > --- a/include/net/bluetooth/rfcomm.h > > +++ b/include/net/bluetooth/rfcomm.h > > @@ -290,7 +290,7 @@ struct rfcomm_conninfo { > > }; > > > > #define RFCOMM_LM 0x03 > > -#define RFCOMM_LM_MASTER 0x0001 > > +#define RFCOMM_LM_CENTRAL 0x0001 > > #define RFCOMM_LM_AUTH 0x0002 > > #define RFCOMM_LM_ENCRYPT 0x0004 > > #define RFCOMM_LM_TRUSTED 0x0008 > > I am not planning to accept this change any time soon since this is also in the libbluetooth API. > > Regards > > Marcel >
From: Archie Pusaka <apusaka@chromium.org> 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(-)