On Tue, Jun 9, 2020 at 12:57 PM David Miller <da...@davemloft.net> wrote: > > From: "Williams, Dan J" <dan.j.willi...@intel.com> > Date: Tue, 9 Jun 2020 19:30:50 +0000 > > > On Tue, 2020-06-09 at 11:36 -0700, David Miller wrote: > >> From: Stephen Hemminger <step...@networkplumber.org> > >> Date: Tue, 9 Jun 2020 10:19:35 -0700 > >> > >> > Yes, words do matter and convey a lot of implied connotation and > >> > meaning. > >> > >> What is your long term plan? Will you change all of the UAPI for > >> bonding for example? > > > > The long term plan in my view includes talking with standards bodies to > > move new content to, for example, master/subordinate. In other words, > > practical forward steps, not retroactively changing interfaces. > > When that knowledge is established legitimately in standards and > transferred into common knowledge of these technologies, yes then > please come present your proposals.
Our hands are not completely tied by the specifications, as a community we have a non-zero level of influence over standards bodies, even direct participation in some. So we could do something stronger than passively wait for standards to catch up. For example, deprecate our consideration of future specifications that include this language and set a cut off date. I understand the confusion that arises from using terminology differently from the specification, but at the same time when specification language actively hurts kernel code maintainability we change it. For example, when I did the first iteration of what eventually became libnvdimm Ingo rightly reacted to the naming being too ACPI specification centric and wanting more kernel-centric naming. If the common kernel name for what was formerly called a "slave" device is a "subordinate" device then the confusion is lessened, only one common kernel translation to consider. > But right now using different words will create confusion. > > I also find master/subordinate an interesting proposal, what if master > is a triggering term? Why only slave? "slave" has a direct connection to human suffering deployed at global scale. One way I think about this is consider we have our first ever Linux Plumbers on the African continent, and you had a choice about giving a talk about how the git master branch operates, or a talk about slave devices which one would you feel more immediately comfortable leading? Any hesitation you would feel freely using the word slave with a predominantly black audience is a similar speed bump a contributor might feel needing to consume that term to get their job done. Explaining "no, not that connotation of slave" does not scale as much as transitioning to another term. > I know people feel something needs to change, but do that moving > forward for the technologies themselves. This is the start of a process that the kernel community can take an active role to lead, we have it within our control to not wait for the lowest common denominator to catch up. > Not how we implement support > for a technology which is established already. > > Plant the seed, don't chop the tree down. I appreciate the engagement.
