[gem5-dev] Re: Request for comments/reviews: Multiple Ruby protocols in a single binary

[Jason Lowe-Power]

Hi all,

I (finally) finished rebasing and updating the changes based on the
feedback. Thank you all for your help on this!

On the to do list before merging:
- Some more comments that may need a bit of back and forth (especially from
Andreas as of 5/26)
- Run the nightly and weekly tests on the tip
- Update the website and release notes

Here's the changes again if anyone else wants to provide feedback :)
https://gem5-review.googlesource.com/q/topic:all-ruby-protocols

Cheers,
Jason

On Tue, Apr 12, 2022 at 1:44 PM Jason Lowe-Power 
wrote:

> Hi all,
>
> I would really appreciate some reviews on these changes. This is something
> that I know many in the development community (Andreas, Gabe, others) have
> been asking for. Please take a look!
>
> I think most changes are pretty straightforward. There is one change where
> I would like some specific feedback on a good way to incorporate multiple
> Ruby protocols into the SConscript (
> https://gem5-review.googlesource.com/c/public/gem5/+/58443/2)
>
> Hi Giacomo,
>
> I dug into the idea you proposed a bit more today, and I'm pretty
> convinced that it would be significant work.
>
> It's possible to make a SimObject be part of a submodule of m5.objects.
> However, the problem comes in the params. I don't think there's an easy way
> to create two params/.hh files for SimObjects which have the
> same name.
>
> Basically, we have a strong assumption in the SimObject generation code
> that no two SimObjects will have exactly the same name. Extending this to
> allow SimObjects with the same name would be quite a bit of effort. Right
> now, I don't believe this effort is worth the benefit for this set of
> changes.
>
> Let me know what you think.
>
> Cheers,
> Jason
>
> On Fri, Apr 1, 2022 at 7:48 AM Jason Lowe-Power 
> wrote:
>
>> Sounds like a good idea. But I don't know how to do this easily. All
>> SimObjects are part of the m5.object module, and this is deeply embedded in
>> many different parts of gem5.
>>
>> My best guess at how to do this would be to add a new type of SimObject
>> which is not in m5.objects, but in a submodule. Then, we would also have to
>> extend the Scons concept of "SimObject" and how scons creates the SimObject
>> params files and the python m5.objects files. My initial thought is that
>> this would be a lot more work. I could be wrong, though.
>>
>> If you have a specific idea on how to implement this, or if you can
>> provide an implementation, I can try to integrate it with what I have done.
>>
>> Either way, it will require non-backwards compatible changes to configs
>> to import the correct module or use the new names. I'm not sure the benefit
>> is worth the investment, though.
>>
>> Let me know what you think :)
>>
>> Cheers,
>> Jason
>>
>>
>>
>> On Fri, Apr 1, 2022 at 7:31 AM Giacomo Travaglini <
>> giacomo.travagl...@arm.com> wrote:
>>
>>> Congrats to Jason and to everyone who’s making this possible!
>>>
>>>
>>>
>>> About the naming, I wonder if we could provide a different python module
>>> per ruby protocol.
>>>
>>> That would allow us to avoid prefixing in favour of something like:
>>>
>>>
>>> $from m5.objects.mi_example import L1Cache_Controller
>>>
>>>
>>>
>>> or
>>>
>>>
>>> $from m5.objects.msi import L1Cache_Controller
>>>
>>>
>>>
>>> Kind Regards
>>>
>>>
>>>
>>> Giacomo
>>>
>>>
>>>
>>>
>>>
>>> *From: *Jason Lowe-Power via gem5-dev 
>>> *Date: *Thursday, 31 March 2022 at 18:43
>>> *To: *gem5 Developer List 
>>> *Cc: *Jason Lowe-Power 
>>> *Subject: *[gem5-dev] Request for comments/reviews: Multiple Ruby
>>> protocols in a single binary
>>>
>>> Hi all,
>>>
>>>
>>>
>>> For as long as gem5 has been gem5, you have had to build a different
>>> gem5 binary if you want to use a different Ruby protocol. Making it
>>> possible to build multiple protocols has been on the roadmap for a long
>>> time (at least as long as I've been involved with the project).
>>>
>>>
>>>
>>> I'm excited to say that we've been able to do this (finally), and we
>>> have a set of changesets on gerrit for review/comments feedback.
>>>
>>>
>>>
>>> There are a couple of todo items before it's merged, and a couple of
>>> user-facing changes that we could not find a way to make fully backwards
>>> compatible. More on this below.
>>>
>>>
>>>
>>> Let me know what you think, and let me know if there are any questions!
>>> I'm excited to see this get in for gem5-22.0.
>>>
>>>
>>>
>>> Changes: https://gem5-review.googlesource.com/q/topic:all-ruby-protocols
>>>
>>>
>>>
>>> *Non-backwards compatible changes:*
>>>
>>> Previously each SLICC protocol used the same names for the same machine
>>> time. E.g., MI_example has an `L1Cache_Controller` and MSI has an
>>> `L1Cache_Controller`. These names were automatically generated from the
>>> MachineType (L1Cache) + "_Controller". Now, since we want to be able to
>>> compile these two protocols at the same time, we need to make sure there
>>> are no (python) name clashes. So, these have been renamed to have the
>>> 

[gem5-dev] Re: Request for comments/reviews: Multiple Ruby protocols in a single binary

[Jason Lowe-Power via gem5-dev]

Hi all,

I would really appreciate some reviews on these changes. This is something
that I know many in the development community (Andreas, Gabe, others) have
been asking for. Please take a look!

I think most changes are pretty straightforward. There is one change where
I would like some specific feedback on a good way to incorporate multiple
Ruby protocols into the SConscript (
https://gem5-review.googlesource.com/c/public/gem5/+/58443/2)

Hi Giacomo,

I dug into the idea you proposed a bit more today, and I'm pretty convinced
that it would be significant work.

It's possible to make a SimObject be part of a submodule of m5.objects.
However, the problem comes in the params. I don't think there's an easy way
to create two params/.hh files for SimObjects which have the
same name.

Basically, we have a strong assumption in the SimObject generation code
that no two SimObjects will have exactly the same name. Extending this to
allow SimObjects with the same name would be quite a bit of effort. Right
now, I don't believe this effort is worth the benefit for this set of
changes.

Let me know what you think.

Cheers,
Jason

On Fri, Apr 1, 2022 at 7:48 AM Jason Lowe-Power  wrote:

> Sounds like a good idea. But I don't know how to do this easily. All
> SimObjects are part of the m5.object module, and this is deeply embedded in
> many different parts of gem5.
>
> My best guess at how to do this would be to add a new type of SimObject
> which is not in m5.objects, but in a submodule. Then, we would also have to
> extend the Scons concept of "SimObject" and how scons creates the SimObject
> params files and the python m5.objects files. My initial thought is that
> this would be a lot more work. I could be wrong, though.
>
> If you have a specific idea on how to implement this, or if you can
> provide an implementation, I can try to integrate it with what I have done.
>
> Either way, it will require non-backwards compatible changes to configs to
> import the correct module or use the new names. I'm not sure the benefit is
> worth the investment, though.
>
> Let me know what you think :)
>
> Cheers,
> Jason
>
>
>
> On Fri, Apr 1, 2022 at 7:31 AM Giacomo Travaglini <
> giacomo.travagl...@arm.com> wrote:
>
>> Congrats to Jason and to everyone who’s making this possible!
>>
>>
>>
>> About the naming, I wonder if we could provide a different python module
>> per ruby protocol.
>>
>> That would allow us to avoid prefixing in favour of something like:
>>
>>
>> $from m5.objects.mi_example import L1Cache_Controller
>>
>>
>>
>> or
>>
>>
>> $from m5.objects.msi import L1Cache_Controller
>>
>>
>>
>> Kind Regards
>>
>>
>>
>> Giacomo
>>
>>
>>
>>
>>
>> *From: *Jason Lowe-Power via gem5-dev 
>> *Date: *Thursday, 31 March 2022 at 18:43
>> *To: *gem5 Developer List 
>> *Cc: *Jason Lowe-Power 
>> *Subject: *[gem5-dev] Request for comments/reviews: Multiple Ruby
>> protocols in a single binary
>>
>> Hi all,
>>
>>
>>
>> For as long as gem5 has been gem5, you have had to build a different gem5
>> binary if you want to use a different Ruby protocol. Making it possible to
>> build multiple protocols has been on the roadmap for a long time (at least
>> as long as I've been involved with the project).
>>
>>
>>
>> I'm excited to say that we've been able to do this (finally), and we have
>> a set of changesets on gerrit for review/comments feedback.
>>
>>
>>
>> There are a couple of todo items before it's merged, and a couple of
>> user-facing changes that we could not find a way to make fully backwards
>> compatible. More on this below.
>>
>>
>>
>> Let me know what you think, and let me know if there are any questions!
>> I'm excited to see this get in for gem5-22.0.
>>
>>
>>
>> Changes: https://gem5-review.googlesource.com/q/topic:all-ruby-protocols
>>
>>
>>
>> *Non-backwards compatible changes:*
>>
>> Previously each SLICC protocol used the same names for the same machine
>> time. E.g., MI_example has an `L1Cache_Controller` and MSI has an
>> `L1Cache_Controller`. These names were automatically generated from the
>> MachineType (L1Cache) + "_Controller". Now, since we want to be able to
>> compile these two protocols at the same time, we need to make sure there
>> are no (python) name clashes. So, these have been renamed to have the
>> protocol name prepended onto the machine name (e.g.,
>> `MI_example_L1Cache_Controller`).
>>
>>
>>
>> For most people using Ruby, we can provide backwards compatibility. If
>> you simply instantiate the `L1Cache_Controller` in python, we can provide a
>> new factory function that does the "right" thing. However, if you inherit
>> from `L1Cache_Controller` to specialize the controller, this won't work.
>>
>>
>>
>> *The user-facing change is* if you have any local ruby protocol
>> configuration files which use inheritance with the controllers, you will
>> have to update the controller classes to use the name of the protocol
>> prepended on the controller name.
>>
>>
>>
>> We have updated all of the 

[gem5-dev] Re: Request for comments/reviews: Multiple Ruby protocols in a single binary

[Jason Lowe-Power via gem5-dev]

Sounds like a good idea. But I don't know how to do this easily. All
SimObjects are part of the m5.object module, and this is deeply embedded in
many different parts of gem5.

My best guess at how to do this would be to add a new type of SimObject
which is not in m5.objects, but in a submodule. Then, we would also have to
extend the Scons concept of "SimObject" and how scons creates the SimObject
params files and the python m5.objects files. My initial thought is that
this would be a lot more work. I could be wrong, though.

If you have a specific idea on how to implement this, or if you can provide
an implementation, I can try to integrate it with what I have done.

Either way, it will require non-backwards compatible changes to configs to
import the correct module or use the new names. I'm not sure the benefit is
worth the investment, though.

Let me know what you think :)

Cheers,
Jason



On Fri, Apr 1, 2022 at 7:31 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Congrats to Jason and to everyone who’s making this possible!
>
>
>
> About the naming, I wonder if we could provide a different python module
> per ruby protocol.
>
> That would allow us to avoid prefixing in favour of something like:
>
>
> $from m5.objects.mi_example import L1Cache_Controller
>
>
>
> or
>
>
> $from m5.objects.msi import L1Cache_Controller
>
>
>
> Kind Regards
>
>
>
> Giacomo
>
>
>
>
>
> *From: *Jason Lowe-Power via gem5-dev 
> *Date: *Thursday, 31 March 2022 at 18:43
> *To: *gem5 Developer List 
> *Cc: *Jason Lowe-Power 
> *Subject: *[gem5-dev] Request for comments/reviews: Multiple Ruby
> protocols in a single binary
>
> Hi all,
>
>
>
> For as long as gem5 has been gem5, you have had to build a different gem5
> binary if you want to use a different Ruby protocol. Making it possible to
> build multiple protocols has been on the roadmap for a long time (at least
> as long as I've been involved with the project).
>
>
>
> I'm excited to say that we've been able to do this (finally), and we have
> a set of changesets on gerrit for review/comments feedback.
>
>
>
> There are a couple of todo items before it's merged, and a couple of
> user-facing changes that we could not find a way to make fully backwards
> compatible. More on this below.
>
>
>
> Let me know what you think, and let me know if there are any questions!
> I'm excited to see this get in for gem5-22.0.
>
>
>
> Changes: https://gem5-review.googlesource.com/q/topic:all-ruby-protocols
>
>
>
> *Non-backwards compatible changes:*
>
> Previously each SLICC protocol used the same names for the same machine
> time. E.g., MI_example has an `L1Cache_Controller` and MSI has an
> `L1Cache_Controller`. These names were automatically generated from the
> MachineType (L1Cache) + "_Controller". Now, since we want to be able to
> compile these two protocols at the same time, we need to make sure there
> are no (python) name clashes. So, these have been renamed to have the
> protocol name prepended onto the machine name (e.g.,
> `MI_example_L1Cache_Controller`).
>
>
>
> For most people using Ruby, we can provide backwards compatibility. If you
> simply instantiate the `L1Cache_Controller` in python, we can provide a new
> factory function that does the "right" thing. However, if you inherit from
> `L1Cache_Controller` to specialize the controller, this won't work.
>
>
>
> *The user-facing change is* if you have any local ruby protocol
> configuration files which use inheritance with the controllers, you will
> have to update the controller classes to use the name of the protocol
> prepended on the controller name.
>
>
>
> We have updated all of the configurations that are in the gem5 repo. You
> will see warnings if you use the old backwards-compatible names (including
> with Ruby.py).
>
>
>
> The only other user-facing change (I think, reviewers, please point out if
> I'm wrong), is that in places that `buildEnv["PROTOCOL"]` was used to check
> the protocol that was built, you will now need to use `getRubyProtocol`
> (also available in `m5.defines`). However, we are currently supporting
> backwards compatibility here, but there will be no warning when we drop
> backwards compatibility (I expect this to be in a couple of releases).
>
>
>
> *To do items*
>
> - Correctly integrate this with scons (and the new kconfig). See
> https://gem5-review.googlesource.com/c/public/gem5/+/58443 for a WIP that
> needs to be updated.
>
> - Update the website. Assuming there are no major flaws in our
> implementation, we will update the website soon (before the changes are
> committed). The main updates are the two user-facing changes described
> above, but I expect some updates to how Ruby/SLICC works as well.
>
> - Add another commit that checks if the protocol is in the list of built
> protocols instead of a single protocol. I'm holding off on this one until
> item #1 is complete. This will also include a new command-line parameter to
> set the "main" protocol for backwards 

[gem5-dev] Re: Request for comments/reviews: Multiple Ruby protocols in a single binary

[Giacomo Travaglini via gem5-dev]

Congrats to Jason and to everyone who’s making this possible!

About the naming, I wonder if we could provide a different python module per 
ruby protocol.
That would allow us to avoid prefixing in favour of something like:

$from m5.objects.mi_example import L1Cache_Controller

or

$from m5.objects.msi import L1Cache_Controller

Kind Regards

Giacomo


From: Jason Lowe-Power via gem5-dev 
Date: Thursday, 31 March 2022 at 18:43
To: gem5 Developer List 
Cc: Jason Lowe-Power 
Subject: [gem5-dev] Request for comments/reviews: Multiple Ruby protocols in a 
single binary
Hi all,

For as long as gem5 has been gem5, you have had to build a different gem5 
binary if you want to use a different Ruby protocol. Making it possible to 
build multiple protocols has been on the roadmap for a long time (at least as 
long as I've been involved with the project).

I'm excited to say that we've been able to do this (finally), and we have a set 
of changesets on gerrit for review/comments feedback.

There are a couple of todo items before it's merged, and a couple of 
user-facing changes that we could not find a way to make fully backwards 
compatible. More on this below.

Let me know what you think, and let me know if there are any questions! I'm 
excited to see this get in for gem5-22.0.

Changes: https://gem5-review.googlesource.com/q/topic:all-ruby-protocols

Non-backwards compatible changes:
Previously each SLICC protocol used the same names for the same machine time. 
E.g., MI_example has an `L1Cache_Controller` and MSI has an 
`L1Cache_Controller`. These names were automatically generated from the 
MachineType (L1Cache) + "_Controller". Now, since we want to be able to compile 
these two protocols at the same time, we need to make sure there are no 
(python) name clashes. So, these have been renamed to have the protocol name 
prepended onto the machine name (e.g., `MI_example_L1Cache_Controller`).

For most people using Ruby, we can provide backwards compatibility. If you 
simply instantiate the `L1Cache_Controller` in python, we can provide a new 
factory function that does the "right" thing. However, if you inherit from 
`L1Cache_Controller` to specialize the controller, this won't work.

The user-facing change is if you have any local ruby protocol configuration 
files which use inheritance with the controllers, you will have to update the 
controller classes to use the name of the protocol prepended on the controller 
name.

We have updated all of the configurations that are in the gem5 repo. You will 
see warnings if you use the old backwards-compatible names (including with 
Ruby.py).

The only other user-facing change (I think, reviewers, please point out if I'm 
wrong), is that in places that `buildEnv["PROTOCOL"]` was used to check the 
protocol that was built, you will now need to use `getRubyProtocol` (also 
available in `m5.defines`). However, we are currently supporting backwards 
compatibility here, but there will be no warning when we drop backwards 
compatibility (I expect this to be in a couple of releases).

To do items
- Correctly integrate this with scons (and the new kconfig). See 
https://gem5-review.googlesource.com/c/public/gem5/+/58443 for a WIP that needs 
to be updated.
- Update the website. Assuming there are no major flaws in our implementation, 
we will update the website soon (before the changes are committed). The main 
updates are the two user-facing changes described above, but I expect some 
updates to how Ruby/SLICC works as well.
- Add another commit that checks if the protocol is in the list of built 
protocols instead of a single protocol. I'm holding off on this one until item 
#1 is complete. This will also include a new command-line parameter to set the 
"main" protocol for backwards compatibility.

Cheers,
Jason

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Request for comments/reviews: Multiple Ruby protocols in a single binary

[Jason Lowe-Power via gem5-dev]

Thanks, Brad!

I *hope* that the downstream work is minimal. There's only one change that
I couldn't figure out a way to make backwards compatible, and it's a very
minor update. BTW, if you have an idea on how to make it backwards
compatible, I'm open to revising. I tried a few different things, but I
couldn't find a solution.

The motivation was twofold:
1. There are two sets of changes pushed by Gabe Black that move us closer
to having a single gem5 binary: the MultiISA changes and the kconfig
changes. When these are merged, Ruby was the only thing holding us back
from having a single gem5 binary. I think that having a single gem5 binary
will be a huge win for our users. In fact, for many users they will only
have to build gem5 once, or maybe not at all, if we distribute a prebuilt
version!
2. Testing will be much easier/faster. I don't have data on this, yet, as
the final contribution to select the protocol at runtime is missing. I'm
waiting for reviews on the scons changes before I tackle the last part.
That said, well over 50% (probably closer to 75% or more) of our testing is
building gem5. If we can reduce the number of different targets, we're
going to see a huge win, even if each build is 10% slower.

I'll say that if we were to merge the changes as-is (which we shouldn't!
there's still at least one large WIP), the compile time would increase. In
fact, it would increase in the worst possible way. SLICC is pretty slow
right now, and it runs once for every protocol during the scons startup.
So, building after a change even to a single file is going to be worse with
this change. Thus, I am advocating for waiting on this change (at least the
part that enables multiple protocols) until after the kconfig changes have
been merged.

Let me know if you have any other questions!

Here's the change that I couldn't figure out how to make backwards
compatible: https://gem5-review.googlesource.com/c/public/gem5/+/58442 I
can go into more details on that changeset, if you'd like.
Here's the change that should not be merged until we have a way to easily
select which protocols to build:
https://gem5-review.googlesource.com/c/public/gem5/+/58443 Everything up to
that change makes no difference to compile time, etc.

Cheers,
Jason

On Thu, Mar 31, 2022 at 12:36 PM Beckmann, Brad 
wrote:

> [AMD Official Use Only]
>
> Hi Jason,
>
>
>
> This is a huge undertaking.  I’m very impressed that you got this the
> work.  Congratulations!
>
>
>
> Your email covers many important aspects of the change, but one item
> missing is the motivation for the change.  Is it primarily compilation
> simplicity?  Now one can build gem5 once and use that binary to run
> multiple different protocols at different times?  If so, can you speak to
> the compilation speedup of compiling all protocols at once versus compiling
> each one individually.  Also does this change allow us to add more tests to
> check-ins because we don’t have to spend as much time building a bunch of
> individual binaries?  Some quantified data could really help motivate the
> downstream work involved to consume this change.
>
>
>
> Thanks!
>
>
>
> Brad
>
>
>
>
>
>
>
>
>
> *From:* Jason Lowe-Power via gem5-dev 
> *Sent:* Thursday, March 31, 2022 9:42 AM
> *To:* gem5 Developer List 
> *Cc:* Jason Lowe-Power 
> *Subject:* [gem5-dev] Request for comments/reviews: Multiple Ruby
> protocols in a single binary
>
>
>
> [CAUTION: External Email]
>
> Hi all,
>
>
>
> For as long as gem5 has been gem5, you have had to build a different gem5
> binary if you want to use a different Ruby protocol. Making it possible to
> build multiple protocols has been on the roadmap for a long time (at least
> as long as I've been involved with the project).
>
>
>
> I'm excited to say that we've been able to do this (finally), and we have
> a set of changesets on gerrit for review/comments feedback.
>
>
>
> There are a couple of todo items before it's merged, and a couple of
> user-facing changes that we could not find a way to make fully backwards
> compatible. More on this below.
>
>
>
> Let me know what you think, and let me know if there are any questions!
> I'm excited to see this get in for gem5-22.0.
>
>
>
> Changes: https://gem5-review.googlesource.com/q/topic:all-ruby-protocols
> 
>
>
>
> *Non-backwards compatible changes:*
>
> Previously each SLICC protocol used the same names for the same machine
> time. E.g., MI_example has an `L1Cache_Controller` and MSI has an
> `L1Cache_Controller`. These names were automatically generated from the
> MachineType (L1Cache) + "_Controller". Now, 

[gem5-dev] Re: Request for comments/reviews: Multiple Ruby protocols in a single binary

[Beckmann, Brad via gem5-dev]

[AMD Official Use Only]

Hi Jason,

This is a huge undertaking.  I'm very impressed that you got this the work.  
Congratulations!

Your email covers many important aspects of the change, but one item missing is 
the motivation for the change.  Is it primarily compilation simplicity?  Now 
one can build gem5 once and use that binary to run multiple different protocols 
at different times?  If so, can you speak to the compilation speedup of 
compiling all protocols at once versus compiling each one individually.  Also 
does this change allow us to add more tests to check-ins because we don't have 
to spend as much time building a bunch of individual binaries?  Some quantified 
data could really help motivate the downstream work involved to consume this 
change.

Thanks!

Brad




From: Jason Lowe-Power via gem5-dev 
Sent: Thursday, March 31, 2022 9:42 AM
To: gem5 Developer List 
Cc: Jason Lowe-Power 
Subject: [gem5-dev] Request for comments/reviews: Multiple Ruby protocols in a 
single binary

[CAUTION: External Email]
Hi all,

For as long as gem5 has been gem5, you have had to build a different gem5 
binary if you want to use a different Ruby protocol. Making it possible to 
build multiple protocols has been on the roadmap for a long time (at least as 
long as I've been involved with the project).

I'm excited to say that we've been able to do this (finally), and we have a set 
of changesets on gerrit for review/comments feedback.

There are a couple of todo items before it's merged, and a couple of 
user-facing changes that we could not find a way to make fully backwards 
compatible. More on this below.

Let me know what you think, and let me know if there are any questions! I'm 
excited to see this get in for gem5-22.0.

Changes: 
https://gem5-review.googlesource.com/q/topic:all-ruby-protocols

Non-backwards compatible changes:
Previously each SLICC protocol used the same names for the same machine time. 
E.g., MI_example has an `L1Cache_Controller` and MSI has an 
`L1Cache_Controller`. These names were automatically generated from the 
MachineType (L1Cache) + "_Controller". Now, since we want to be able to compile 
these two protocols at the same time, we need to make sure there are no 
(python) name clashes. So, these have been renamed to have the protocol name 
prepended onto the machine name (e.g., `MI_example_L1Cache_Controller`).

For most people using Ruby, we can provide backwards compatibility. If you 
simply instantiate the `L1Cache_Controller` in python, we can provide a new 
factory function that does the "right" thing. However, if you inherit from 
`L1Cache_Controller` to specialize the controller, this won't work.

The user-facing change is if you have any local ruby protocol configuration 
files which use inheritance with the controllers, you will have to update the 
controller classes to use the name of the protocol prepended on the controller 
name.

We have updated all of the configurations that are in the gem5 repo. You will 
see warnings if you use the old backwards-compatible names (including with 
Ruby.py).

The only other user-facing change (I think, reviewers, please point out if I'm 
wrong), is that in places that `buildEnv["PROTOCOL"]` was used to check the 
protocol that was built, you will now need to use `getRubyProtocol` (also 
available in `m5.defines`). However, we are currently supporting backwards 
compatibility here, but there will be no warning when we drop backwards 
compatibility (I expect this to be in a couple of releases).

To do items
- Correctly integrate this with scons (and the new kconfig). See 
https://gem5-review.googlesource.com/c/public/gem5/+/58443
 for a WIP that needs to be updated.
- Update the website. Assuming there are no major flaws in our implementation, 
we will update the website soon (before the changes are committed). The main 
updates are the two user-facing changes described above, but I expect some 
updates to how Ruby/SLICC works as well.
- Add another commit that checks if the protocol is in the list of built 
protocols instead of a single protocol. I'm holding off on this one until item 
#1 is complete. This will also include