Times change. People, even engineers, eventually “clue up.”
As people become sensitive to the negative impact that the names of things can have on those who don’t share their own ethnic, racial, cultural, or social background, they get on board with the idea of changing those names. Sometimes the changes are simple; As easy as replacing one troublesome term with an equally good neutral term. Other times, finding suitable replacement terms can be extremely difficult. But change we must. That is non-negotiable.
But what is also non-negotiable is that we must not merely substitute arbitrary, confusing, awkward, or downright silly names for those terms that are no longer acceptable. Jettisoning rude or unacceptable terms by replacing them with random, inoffensive, names is not helpful to the overall industry. When we engage in random, thoughtless, substitution or terms with the sole goal of ridding ourselves of offensive terminology at any price, we do a disservice to our profession.
The ultimate pair of offensive terms in engineering is perhaps one of the longest tenured. There are many technologies within computer engineering that use the terms “master” and “slave” to denote the controlling and the controlled components, respectively, of a system. This is so pervasive, so well known, and so troublesome, that it even drew the attention of the Washington Post, back in 2020.
Probably one of the oldest uses of this term in our industry is in describing Direct Memory Access (DMA) systems. Most particularly, in Windows we make a distinction between bus-master DMA and what has traditionally been called “slave DMA.” There was an initial proposal, made many years ago, to replace the term “slave DMA” in the Windows Driver Kit (WDK) docs with “subordinate DMA.” At the time, I raised a vociferous objection, and likely helped cause that the old term to be retained for a number of years. My argument was that inventing a new, confusing, term for a technology that was widely known by another name was silly, gratuitous, and sure to hamper people’s understanding. At the time, I was not interested in considering anybody else’s thoughts on the matter (not even a little). What mattered was established industry practice and clarity. And if you, for some reason, didn’t like that terminology? Well, you just need to get over it.
But I was, in my own self-absorbed way, on to something (even if I didn’t know it at the time): Replacing a troublesome term with a bad term is not a net good. Sure, the new, ill-fitting, term may no longer be offensive. Instead, it’s confusing. And, while that’s arguably an improvement, it’s not (even today, in 2022) improvement enough in my book.
More recently (and, ahem, without asking me) the WDK docs changed the term “slave DMA” to “system DMA.” Not only does this new term entirely avoid the implications of the older term, but I think it better describes the way this type of DMA works and is implemented in Windows system. The old term’s offensiveness is gone; Clarity is retained, or perhaps even enhanced. Win-Win. Score one for the WDK writers.
Fast forward to the 21st Century. Specifically, to 2019. I was creating some slides for our WDF I seminar about the SPI and I2C buses, and I wanted to explain some of the basic concepts of these buses to our students, in case they weren’t already familiar with them. So, being the lazy developer that I am, I “borrowed” some bus diagrams that I found on the Internet:
Notice how our old enemies, the terms “master” and “slave” show-up again here. And they show up not only in denoting the parties involved in the communications, but in the case of the SPI bus, they also show up in the names of the signals. See table 1.
|Master Out, Slave In
|Master In, Slave Out
|Slave Select (x)
Looking at Table 1, you can see that in both SPI and I2C the clock signals (SCLK and SCL, respectively) are named “serial clock” — but those other signals unabashedly use the problematic “master” and “slave” terms.
At first, I had no trouble with these older names. Hey, “they are what they are”, right? They’re industry standard! But, by the time 2020 rolled around I started to feel distinctly…. ah… awkward… uncomfortable, even… teaching these terms in class. Call it a delayed awakening or something, OK?
So, I started to search for updated, industry standard, names. And guess what? There weren’t any. The best I could find where some arguments on reddit (you can imagine how clever and useful those were), and some proposals for updated names on individual sites (thank you, Adafruit). So, I made some slide changes to eliminate those problematic terms (along the lines of the ones suggested at the time by Adafruit) and went on teaching the seminars sans the problematic terminology.
Now, it seems that as of 2022 the Open Source Hardware Association has defined a set of new “standardized” signal names that avoid the troublesome terminology, and that seem to be every bit as good (and pronounceable) as the old signal names. They describe these new names here. The new names are shown in Table 2.
|Peripheral In, Controller Out
|Peripheral Out, Controller In
As you can see in Table 2, the new terminology aligns quite nicely with the names for the actual hardware components: The chip that manages the protocol-based bus is the controller, and the chip that responds to requests from the controller is the peripheral. This also maps quite nicely to the WDK terminology for the types of drivers: Controller drivers (typically supplied by MSFT or the OEM) and peripheral drivers (typically supplied by the IHV, and what we talk about writing in our WDF seminars).
And so, we now have new diagrams for our WDF seminar as well:
Changing established industry practice takes time. Changing people’s minds takes even longer. We should not, and do not have to, sacrifice engineering clarity, mnemonic ability, or ease of use when addressing old, archaic, and potentially hurtful terminology. “Subordinate DMA”? Yeah… no. But “System DMA”? Yes, that makes sense. Been saying “MOSI” all your career long? Well, I’d suggest “PICO” is actually a better term. We live, we do engineering, we argue… we learn.