We're updating the issue view to help you get more done. 

Remove master/slave terminology


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.)


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).


  1. Create a RequestPort and ResponsePort

  2. Make Master/SlavePorts a deprecated subclass

  3. Find all uses of MasterPort and SlavePort

  4. 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 MasterId and the MasterInfo. We should rename these objects to something else.

  • MasterId->`RequestorId`

  • MasterInfo->`RequestorInfo`


Andreas Sandberg
September 3, 2020, 3:01 PM

The main benefit would be in function calls where parameter types would be enforced. An old-style enum (or just a typedef:ed int) would happily be used in a place where an Addr or some other int-like type is expected.

I think we could avoid some of the casts by overloading operators that compare a RequestorId to an int. That’s actually one of the benefits of enum classes. Unfortunately, we would still have to explicitly cast it to an int when indexing into arrays (another option would be to build a templatised helper function that returns a reference to an element and performs bounds checking).

Jason Lowe-Power
September 3, 2020, 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

Andreas Sandberg
September 3, 2020, 3:18 PM

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.

Lakin Smith
September 4, 2020, 1:15 AM

Here are the recent changes for replacing all master/slave terminology:


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:
masterrequestor (this also applies for any name that has master/slave in it not followed by ‘port’, i.e. masterObject → requestorObject)
(originally masterId) _id_requestorId
master_portrequest_port or mem_side_port(s)
slave_portresponse_port or cpu_side_port(s)

Please take a look at the changes and give any feedback!

September 11, 2020, 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.


Shivani Parekh


Jason Lowe-Power




Epic Link


Fix versions