Remove master/slave terminology
Description
Activity
Jason Lowe-Power March 29, 2021 at 9:09 PM
Marking as done!
Former user September 11, 2020 at 10:15 AM
This epic should not be marked as done, since there is still deprecation to be completed, and other instances to be renamed, both within and out of the src directory. The subtasks, however, do not present any relevant information; thus, they should be either filled or removed.
Lakin Smith September 4, 2020 at 1:15 AM
Here are the recent changes for replacing all master/slave terminology:
https://gem5-review.googlesource.com/c/public/gem5/+/33553
All changes have been squished into one change set, so it should be easier to see what’s been changed or missed. All class names, variable names, comments, and function names should be changed at this point. Previous comments made should also be addressed in this change, including camel casing the appropriate variables and changing _id to requestorId.
For reference, this is the general guideline followed for renaming:master → requestor (this also applies for any name that has master/slave in it not followed by ‘port’, i.e. masterObject → requestorObject)slave → responderMasterID → RequestorID
(originally masterId) _id→ _requestorIdmaster_port → request_port or mem_side_port(s)slave_port → response_port or cpu_side_port(s)
Please take a look at the changes and give any feedback!
Andreas Sandberg September 3, 2020 at 3:18 PMEdited
I think you are right. Enforcing stricter typing shouldn’t be a blocker for this. We should probably open a separate ticket for that. I would like to fix the same issue for Addr, which is currently a bit fragile.
One possible way to (temporarily) workaround would be to provide operator int() for the enum class. That should solve many of the problems.
Jason Lowe-Power September 3, 2020 at 3:11 PM
For the array accesses, it’s mostly to index into vectored stats. We may be able to write a special accessor in the stats for RequestorID.
My point isn’t that this is a bad idea or impossible, just that’s it’s complex and end the end may not be worth the extra complexity.
I’m not taking a position here
Note: Some of these names are in python parameters. Thus, we are going to have to add warnings to let people know the changes are coming.
We need to update this outdated and problematic terminology. See for instance this WaPo article: https://www.washingtonpost.com/opinions/2020/06/12/tech-industry-has-an-ugly-master-slave-problem/ and this Wired article: https://www.wired.com/story/tech-confronts-use-labels-master-slave/. The main goal is to improve the usability of gem5 by providing more descriptive terminology.
There are a few different ways that gem5 uses the masters/slave terminology that need to be updated in different ways. Note that in most cases “master” corresponds to “requestor” and “slave” corresponds to receiver or responder.
(A side note on style/spelling. The spelling “requestor” (with an 'o') is shown as wrong in most spellcheckers and style guides. However, this is the common spelling in networking/technology. See https://english.stackexchange.com/questions/29254/whats-the-difference-between-requester-and-requestor for an example discussion on this.)
Ports
We now have `RequestPort` and `ResponsePort` in Python, but we need to make the same change in C++.
Most of the uses of master/slave can be easily replaced with Request/Response in this case. We should keep the [Master/Slave]Port classes around for at least one release (and mark them as deprecated).
Steps:
Create a RequestPort and ResponsePort
Make Master/SlavePorts a deprecated subclass
Find all uses of MasterPort and SlavePort
Replace these with RequestPort and ResponsePort
Original Requestor
Another way “master” is used is to refer to the original object that made the request. This is useful for things like tracking the bandwidth per CPU at the memory controllers.
This information is currently encoded in a
MasterIdand theMasterInfo. We should rename these objects to something else.MasterId->`RequestorId`MasterInfo->`RequestorInfo`