[gem5-dev] Change in gem5/gem5[master]: base: change logger exit behavior
Brandon Potter has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23683 )
Change subject: base: change logger exit behavior
..
base: change logger exit behavior
Under the old behavior, googletest tests with failing
statements throw an empty exception and then abort.
The behavior causes a problem in death/exit tests caused
by fatal statements since the googletest interface
is designed to either catch an exception or die. The
googletest interface does not provide a method to catch
an exception and then die.
With the googletest interface, you'd end up with something
resembling the following:
statement which fails:
Obj obj_fail_in_constructor();
googletest:
ASSERT_ANY_THROW(Obj obj_fail_in_constructor());
ASSERT_EXIT(Obj obj_fail_in_constructor(), "");
The ASSERT_ANY_THROW does not work in isolation because the
constructor fails immediately after the exception is handled
by the API.
The ASSERT_EXIT does not work in isolation because the
exception surfaces immediately before the exit.
The changeset simplifies the logger's exit_helper method to
just directly call the stdlib exit instead of tunneling
into the googletest logger's exit method. It avoids the
empty exception being thrown.
The result allows ASSERT_EXIT to be called within googletest
death tests to handle gem5's fatal calls.
Change-Id: Ifdd1769e398feea3f9ff06b88037d26398b32ee1
---
M src/base/gtest/logging.cc
M src/base/logging.cc
M src/base/logging.hh
3 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/src/base/gtest/logging.cc b/src/base/gtest/logging.cc
index 92d2602..3139d66 100644
--- a/src/base/gtest/logging.cc
+++ b/src/base/gtest/logging.cc
@@ -35,14 +35,6 @@
namespace {
-// This custom exception type will help prevent fatal exceptions from being
-// caught by other code in gem5 and let them escape to the gtest framework.
-// Unfortunately that results in a somewhat confusing message about an
unknown
-// exception being thrown after the panic/fatal message has been printed,
but
-// there will at least be some indication what went wrong.
-struct GTestException
-{};
-
class GTestLogger : public Logger
{
public:
@@ -63,8 +55,6 @@
{
ADD_FAILURE_AT(loc.file, loc.line) << s;
}
-// Throw an exception to escape down to the gtest framework.
-void exit() override { throw GTestException(); }
};
GTestExitLogger panicLogger("panic: ");
diff --git a/src/base/logging.cc b/src/base/logging.cc
index adc3deb..6205a95 100644
--- a/src/base/logging.cc
+++ b/src/base/logging.cc
@@ -73,17 +73,8 @@
}
};
-class FatalLogger : public ExitLogger
-{
- public:
-using ExitLogger::ExitLogger;
-
- protected:
-void exit() override { ::exit(1); }
-};
-
ExitLogger panicLogger("panic: ");
-FatalLogger fatalLogger("fatal: ");
+ExitLogger fatalLogger("fatal: ");
NormalLogger warnLogger("warn: ");
NormalLogger infoLogger("info: ");
NormalLogger hackLogger("hack: ");
diff --git a/src/base/logging.hh b/src/base/logging.hh
index 7040037..f3f413b 100644
--- a/src/base/logging.hh
+++ b/src/base/logging.hh
@@ -121,13 +121,12 @@
// This helper is necessary since noreturn isn't inherited by virtual
// functions, and gcc will get mad if a function calls panic and then
// doesn't return.
-void exit_helper() M5_ATTR_NORETURN { exit(); ::abort(); }
+void exit_helper() M5_ATTR_NORETURN { exit(1); }
protected:
bool enabled;
virtual void log(const Loc &loc, std::string s) = 0;
-virtual void exit() { /* Fall through to the abort in exit_helper. */ }
const char *prefix;
};
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23683
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: Ifdd1769e398feea3f9ff06b88037d26398b32ee1
Gerrit-Change-Number: 23683
Gerrit-PatchSet: 1
Gerrit-Owner: Brandon Potter
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: base: Fix AddrRange::isSubset() check
Nikos Nikoleris has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23663 )
Change subject: base: Fix AddrRange::isSubset() check
..
base: Fix AddrRange::isSubset() check
Making _end non-inclusive, introduced a bug in isSubset() which was
checking if _end is included in the input address range. This CL
changes the behavior and now we test if _end - 1 is in the range.
Change-Id: Ib8822472b7c266e10d55f3d5cf22a46aa45c1fc7
Signed-off-by: Nikos Nikoleris
---
M src/base/addr_range.hh
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/base/addr_range.hh b/src/base/addr_range.hh
index 2a18551..f53c08b 100644
--- a/src/base/addr_range.hh
+++ b/src/base/addr_range.hh
@@ -390,7 +390,7 @@
// whether it would fit in a continuous segment of the input
// addr range.
if (r.interleaved()) {
-return r.contains(_start) && r.contains(_end) &&
+return r.contains(_start) && r.contains(_end - 1) &&
size() <= r.granularity();
} else {
return _start >= r._start && _end <= r._end;
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23663
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: Ib8822472b7c266e10d55f3d5cf22a46aa45c1fc7
Gerrit-Change-Number: 23663
Gerrit-PatchSet: 1
Gerrit-Owner: Nikos Nikoleris
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: dev-virtio, configs: expose 9p diod virtio on ARM
Ciro Santilli has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/22831 )
Change subject: dev-virtio,configs: expose 9p diod virtio on ARM
..
dev-virtio,configs: expose 9p diod virtio on ARM
9p allows the guest Linux kernel to mount a host directory into the guest.
This allows to very easily modify test programs after a run at the end of
boot, without the need to re-insert the changes into a disk image.
It is enabled on both fs.py and fs_bigLITTLE.py with the --vio-9p
option.
Adapted from code originally present on the wiki: http://gem5.org/WA-gem5
As documented in the CLI option help, the current setup requires the guest
to know the full path to the host share, which is annoying, but overcoming
that would require actually parsing a bit of the protocol rather than just
forwarding everything to diod.
Change-Id: Iaeb1ed185dccfa8332fe6657a54e7550f64230eb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22831
Reviewed-by: Jason Lowe-Power
Reviewed-by: Giacomo Travaglini
Maintainer: Jason Lowe-Power
Tested-by: kokoro
---
M configs/common/FSConfig.py
M configs/common/Options.py
M configs/example/arm/fs_bigLITTLE.py
M configs/example/fs.py
4 files changed, 50 insertions(+), 9 deletions(-)
Approvals:
Jason Lowe-Power: Looks good to me, but someone else must approve; Looks
good to me, approved
Giacomo Travaglini: Looks good to me, approved
kokoro: Regressions pass
diff --git a/configs/common/FSConfig.py b/configs/common/FSConfig.py
index 55a6e91..ecc5f1c 100644
--- a/configs/common/FSConfig.py
+++ b/configs/common/FSConfig.py
@@ -42,6 +42,7 @@
from __future__ import print_function
from __future__ import absolute_import
+import m5
from m5.objects import *
from m5.util import *
from .Benchmarks import *
@@ -71,6 +72,19 @@
badaddr_responder = BadAddr()
default = Self.badaddr_responder.pio
+def attach_9p(parent, bus):
+viopci = PciVirtIO()
+viopci.vio = VirtIO9PDiod()
+viodir = os.path.join(m5.options.outdir, '9p')
+viopci.vio.root = os.path.join(viodir, 'share')
+viopci.vio.socketPath = os.path.join(viodir, 'socket')
+if not os.path.exists(viopci.vio.root):
+os.makedirs(viopci.vio.root)
+if os.path.exists(viopci.vio.socketPath):
+os.remove(viopci.vio.socketPath)
+parent.viopci = viopci
+parent.attachPciDevice(viopci, bus)
+
def fillInCmdline(mdesc, template, **kwargs):
kwargs.setdefault('disk', mdesc.disk())
kwargs.setdefault('rootdev', mdesc.rootdev())
@@ -206,7 +220,8 @@
def makeArmSystem(mem_mode, machine_type, num_cpus=1, mdesc=None,
dtb_filename=None, bare_metal=False, cmdline=None,
- external_memory="", ruby=False, security=False):
+ external_memory="", ruby=False, security=False,
+ vio_9p=None):
assert machine_type
pci_devices = []
@@ -374,6 +389,9 @@
self.terminal = Terminal()
self.vncserver = VncServer()
+if vio_9p:
+attach_9p(self.realview, self.iobus)
+
if not ruby:
self.system_port = self.membus.slave
diff --git a/configs/common/Options.py b/configs/common/Options.py
index c47d4f7..71d22a4 100644
--- a/configs/common/Options.py
+++ b/configs/common/Options.py
@@ -48,6 +48,16 @@
from .Benchmarks import *
from . import ObjectList
+vio_9p_help = """\
+Enable the Virtio 9P device and set the path to share. The default 9p path
is
+m5ou5/9p/share, and it can be changed by setting VirtIO9p.root with
--param. A
+sample guest mount command is: "mount -t 9p -o
+trans=virtio,version=9p2000.L,aname= gem5 /mnt/9p" where
+"" is the full path being shared on the host, and "gem5"
is a
+fixed mount tag. This option requires the diod 9P server to be installed
in the
+host PATH or selected with with: VirtIO9PDiod.diod.
+"""
+
def _listCpuTypes(option, opt, value, parser):
ObjectList.cpu_list.print()
sys.exit(0)
@@ -434,6 +444,7 @@
parser.add_option("--enable-context-switch-stats-dump", \
action="store_true", help="Enable stats dump at context "\
"switches and dump tasks file (required for Streamline)")
+parser.add_option("--vio-9p", action="store_true",
help=vio_9p_help)
# Benchmark options
parser.add_option("--dual", action="store_true",
diff --git a/configs/example/arm/fs_bigLITTLE.py
b/configs/example/arm/fs_bigLITTLE.py
index 94e2846..4645d9e 100644
--- a/configs/example/arm/fs_bigLITTLE.py
+++ b/configs/example/arm/fs_bigLITTLE.py
@@ -52,8 +52,10 @@
m5.util.addToPath("../../")
+from common import FSConfig
from common import SysPaths
from common import ObjectList
+from common import Options
from common.cores.arm import ex5_big, ex5_LITTLE
import devices
@@ -209,6 +211,8 @@
"sets max_insts_all_threads for cpus 0, 1, 3, 5 and 7 "
"Direct parameters of the root
[gem5-dev] Change in gem5/gem5[master]: dev-virtio: don't set the 9p default root
Ciro Santilli has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/22828 )
Change subject: dev-virtio: don't set the 9p default root
..
dev-virtio: don't set the 9p default root
It is better to force users to explicitly set this argument, since
it is unlikely that we will find one safe option for all users.
Change-Id: I612520a44efd205a029a40cd13402584d16e1d88
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22828
Tested-by: kokoro
Reviewed-by: Bobby R. Bruce
Reviewed-by: Jason Lowe-Power
Maintainer: Jason Lowe-Power
---
M src/dev/virtio/VirtIO9P.py
1 file changed, 1 insertion(+), 1 deletion(-)
Approvals:
Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
Bobby R. Bruce: Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/dev/virtio/VirtIO9P.py b/src/dev/virtio/VirtIO9P.py
index 55008ae..7c5e132 100644
--- a/src/dev/virtio/VirtIO9P.py
+++ b/src/dev/virtio/VirtIO9P.py
@@ -60,7 +60,7 @@
cxx_header = 'dev/virtio/fs9p.hh'
diod = Param.String("diod", "Path to diod, optionally in PATH")
-root = Param.String("/tmp", "Path to export through diod")
+root = Param.String("Path to export through diod")
socketPath = Param.String("Unused socket to diod")
class VirtIO9PSocket(VirtIO9PProxy):
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/22828
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I612520a44efd205a029a40cd13402584d16e1d88
Gerrit-Change-Number: 22828
Gerrit-PatchSet: 6
Gerrit-Owner: Ciro Santilli
Gerrit-Reviewer: Bobby R. Bruce
Gerrit-Reviewer: Ciro Santilli
Gerrit-Reviewer: Jason Lowe-Power
Gerrit-Reviewer: kokoro
Gerrit-CC: Giacomo Travaglini
Gerrit-MessageType: merged
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: dev-virtio: VIO9P turns on diod verbose output with -d 1
Ciro Santilli has submitted this change. ( https://gem5-review.googlesource.com/c/public/gem5/+/22829 ) Change subject: dev-virtio: VIO9P turns on diod verbose output with -d 1 .. dev-virtio: VIO9P turns on diod verbose output with -d 1 Change-Id: I97e5762f4aca384068b87e22902e071fa3014ceb Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22829 Tested-by: kokoro Reviewed-by: Bobby R. Bruce Maintainer: Bobby R. Bruce --- M src/dev/virtio/fs9p.cc 1 file changed, 1 insertion(+), 0 deletions(-) Approvals: Bobby R. Bruce: Looks good to me, approved; Looks good to me, approved kokoro: Regressions pass diff --git a/src/dev/virtio/fs9p.cc b/src/dev/virtio/fs9p.cc index 87333b6..d763f2c 100644 --- a/src/dev/virtio/fs9p.cc +++ b/src/dev/virtio/fs9p.cc @@ -394,6 +394,7 @@ // Start diod execlp(diod, diod, + "-d", DTRACE(VIO9P) ? "1" : "0", // show debug output "-f", // start in foreground "-r", "3", // setup read FD "-w", "4", // setup write FD -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/22829 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I97e5762f4aca384068b87e22902e071fa3014ceb Gerrit-Change-Number: 22829 Gerrit-PatchSet: 6 Gerrit-Owner: Ciro Santilli Gerrit-Reviewer: Bobby R. Bruce Gerrit-Reviewer: Ciro Santilli Gerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: kokoro Gerrit-CC: Giacomo Travaglini Gerrit-MessageType: merged ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: dev-virtio: use diod basename as the default 9p path
Ciro Santilli has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/22827 )
Change subject: dev-virtio: use diod basename as the default 9p path
..
dev-virtio: use diod basename as the default 9p path
This allows diod to be present anywhere in the PATH by default,
which works because we are already using execlp.
Change-Id: I9d0b6c9a75f32cf0cb5d8f52bb00c465e4d43e1b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22827
Tested-by: kokoro
Reviewed-by: Bobby R. Bruce
Maintainer: Jason Lowe-Power
---
M src/dev/virtio/VirtIO9P.py
1 file changed, 1 insertion(+), 1 deletion(-)
Approvals:
Bobby R. Bruce: Looks good to me, approved
Jason Lowe-Power: Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/dev/virtio/VirtIO9P.py b/src/dev/virtio/VirtIO9P.py
index 02e50f3..55008ae 100644
--- a/src/dev/virtio/VirtIO9P.py
+++ b/src/dev/virtio/VirtIO9P.py
@@ -59,7 +59,7 @@
type = 'VirtIO9PDiod'
cxx_header = 'dev/virtio/fs9p.hh'
-diod = Param.String("/usr/sbin/diod", "Path to diod")
+diod = Param.String("diod", "Path to diod, optionally in PATH")
root = Param.String("/tmp", "Path to export through diod")
socketPath = Param.String("Unused socket to diod")
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/22827
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I9d0b6c9a75f32cf0cb5d8f52bb00c465e4d43e1b
Gerrit-Change-Number: 22827
Gerrit-PatchSet: 6
Gerrit-Owner: Ciro Santilli
Gerrit-Reviewer: Bobby R. Bruce
Gerrit-Reviewer: Ciro Santilli
Gerrit-Reviewer: Jason Lowe-Power
Gerrit-Reviewer: kokoro
Gerrit-CC: Giacomo Travaglini
Gerrit-MessageType: merged
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] gem5 19.0.0 : New git branching proposal
Hi devs, A lot has been said and it is difficult to address most of the interesting opinions that have been raised throughout the conversation. In general I am a moderate fan of releases and I strongly agree with Daniel's story: There is a lot of discussion about when users should be updating their gem5 versions, but how many even want to update? "You don't change a winning team" is something that I've heard a lot from teachers and colleagues during my former studies: why would you risk updating and breaking something, or reducing performance improvements? Throughout the years I've seen that students (me included) tend not to update anything (OS, compiler, software being used) until their work is done out of fear of having to reconfigure/fix things. I got asked several times which stable version should someone use. It is very weird and scary for a user who's willing to rebase his work to get a commit Id as an answer. Especially if there is no bug-fixing happening on a commitId. In fact, if you don't backport bug fixes, the entire concept of stableness is flawed, since you might discover a new bug later on and you are basically forcing a USER (not an active developer) to rebase his work in order to integrate the bug. (A user could cherry-pick the commit on his own, but first he needs to be aware that a specific commit is fixing his problem) I think we all agree that having a linear chunck of untagged and unbranched commits makes it difficult for common users to understand what they are getting when they rebase their work. It is not for some of us maybe, spending most of our engineering time reviewing patches and contributing to gerrit. I could more or less tell what's the difference in the simulator between today's gem5 and last month gem5, but that doesn't apply to the rest of the people. Giacomo From: gem5-dev on behalf of Daniel Carvalho Sent: 13 December 2019 11:32 To: gem5 Developer List Subject: Re: [gem5-dev] gem5 19.0.0 : New git branching proposal A bit late to the party, but here are my two cents. Regarding developing, based on previous experiences and questions I've received from users throughout these years, I couldn't agree more with Jason's sentence: "My experience with architecture grad students and researchers is that if you don't force them to use things like git most of them won't". I've also asked some of these users their preference, and the stable version on master with a development branch was an unanimous pick. However, it seems that this choice was made mostly because it'd require less learning effort; and I am positive not needing to know anything about git was appealing to some (i.e., "git clone" would be the first and last git command they'd use). Therefore, I am not sure this approach will achieve the intended goal of "directing to correct usage". There is a lot of discussion about when users should be updating their gem5 versions, but how many even want to update? "You don't change a winning team" is something that I've heard a lot from teachers and colleagues during my former studies: why would you risk updating and breaking something, or reducing performance improvements? Throughout the years I've seen that students (me included) tend not to update anything (OS, compiler, software being used) until their work is done out of fear of having to reconfigure/fix things. In the end I think that the focus of stable versions should be on reproducibility, not on updatability: researchers will inform which gem5 tag they are using, making it less difficult for readers to reproduce their results. There will obviously be users updating, but changing from possibly having to rebase on every commit to once or twice a year seems like a reasonable compromise given the benefits; the versioning will make updates start to feel more like upgrades, and API changes switch from a constant fear to a short term agreement. There is no need to say that in any case API changes must be made carefully and as infrequently as possible. Personally, I think major and minor differences should not differ as of now; this would complicate reviewing and merging, adding a "when should this go?" to an already complex process. I am not saying this is not possible, but maybe it'd be aiming too high and it would be better to take smaller steps. Overall, the ideas are excellent, and if they manage to leave the theory plane, it will be a great improvement! Looking forward to what's in the future. Regards, Daniel Em sexta-feira, 13 de dezembro de 2019 02:16:05 GMT+1, Jason Lowe-Power escreveu: Ok... so are you suggesting there be no difference between major and minor releases? How do you suggest communicating that API changes are coming? The most common way to do this is by marking functions as deprecated for some period of time. Thanks, Jason On Thu, Dec 12, 2019 at 4:26 PM Gabe Black wrote: > I think that's wha
Re: [gem5-dev] gem5 19.0.0 : New git branching proposal
A bit late to the party, but here are my two cents. Regarding developing, based on previous experiences and questions I've received from users throughout these years, I couldn't agree more with Jason's sentence: "My experience with architecture grad students and researchers is that if you don't force them to use things like git most of them won't". I've also asked some of these users their preference, and the stable version on master with a development branch was an unanimous pick. However, it seems that this choice was made mostly because it'd require less learning effort; and I am positive not needing to know anything about git was appealing to some (i.e., "git clone" would be the first and last git command they'd use). Therefore, I am not sure this approach will achieve the intended goal of "directing to correct usage". There is a lot of discussion about when users should be updating their gem5 versions, but how many even want to update? "You don't change a winning team" is something that I've heard a lot from teachers and colleagues during my former studies: why would you risk updating and breaking something, or reducing performance improvements? Throughout the years I've seen that students (me included) tend not to update anything (OS, compiler, software being used) until their work is done out of fear of having to reconfigure/fix things. In the end I think that the focus of stable versions should be on reproducibility, not on updatability: researchers will inform which gem5 tag they are using, making it less difficult for readers to reproduce their results. There will obviously be users updating, but changing from possibly having to rebase on every commit to once or twice a year seems like a reasonable compromise given the benefits; the versioning will make updates start to feel more like upgrades, and API changes switch from a constant fear to a short term agreement. There is no need to say that in any case API changes must be made carefully and as infrequently as possible. Personally, I think major and minor differences should not differ as of now; this would complicate reviewing and merging, adding a "when should this go?" to an already complex process. I am not saying this is not possible, but maybe it'd be aiming too high and it would be better to take smaller steps. Overall, the ideas are excellent, and if they manage to leave the theory plane, it will be a great improvement! Looking forward to what's in the future. Regards, Daniel Em sexta-feira, 13 de dezembro de 2019 02:16:05 GMT+1, Jason Lowe-Power escreveu: Ok... so are you suggesting there be no difference between major and minor releases? How do you suggest communicating that API changes are coming? The most common way to do this is by marking functions as deprecated for some period of time. Thanks, Jason On Thu, Dec 12, 2019 at 4:26 PM Gabe Black wrote: > I think that's what the release vs. development branch split already > provides. If you want stable interfaces, then the release branch will stay > as it is for a year, or forever if you don't move to new releases. > > Gabe > > On Thu, Dec 12, 2019 at 4:18 PM Jason Lowe-Power > wrote: > > > Thanks Gabe! > > > > I think we're mostly in agreement. The key disagreement is the following: > > > > Note that I'm not advocating for a wild west free for all with no > > > accountability, but only being able to make changes to "interfaces" > > (which > > > pretty much everything could be considered) once a year is much too far > > in > > > the other direction, especially on a so called development branch. > > > > > > I believe, and I've heard from many gem5 users, that we need to have more > > stable interfaces. I think that once a year is a good compromise, but I'm > > open to a faster cadence. Either way, we must give a heads up of at least > > months to change an interface. > > > > Can you propose a different idea that will satisfy our need to both > > provided stability and allow developers to update code? > > > > Alternatively, maybe we need to come up with a better transition than > just > > "tomorrow you can't modify interfaces." Do you have any ideas on a more > > smooth transition to this development model of providing stability to our > > users? > > > > Thanks, > > Jason > > > > On Thu, Dec 12, 2019 at 4:03 PM Gabe Black wrote: > > > > > I'll point out that nobody had to rebase O3 when, for example, the > > > ExecContext changed, because it was already in the tree and was changed > > > along with everything else. > > > > > > I think you have an important contradiction in your reasoning above, > > namely > > > that gem5 is simultaneously too unstable and too stable. You're saying > > it's > > > too unstable since the interfaces change too often, but then also say > > that > > > there have been very few new features in gem5 in the last few years. > > > > > > Fundamentally, new features require changing things. If we clamp down > on >
[gem5-dev] Change in gem5/gem5[master]: arm: Add a header for IRIS MSN constants.
Gabe Black has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23643 )
Change subject: arm: Add a header for IRIS MSN constants.
..
arm: Add a header for IRIS MSN constants.
Change-Id: I06a7d7db95ec1ce65945c9e09f812f0b69aaa8e6
---
A src/arch/arm/fastmodel/iris/memory_spaces.hh
1 file changed, 55 insertions(+), 0 deletions(-)
diff --git a/src/arch/arm/fastmodel/iris/memory_spaces.hh
b/src/arch/arm/fastmodel/iris/memory_spaces.hh
new file mode 100644
index 000..02823d6
--- /dev/null
+++ b/src/arch/arm/fastmodel/iris/memory_spaces.hh
@@ -0,0 +1,55 @@
+/*
+ * Copyright 2019 Google, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met: redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer;
+ * redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution;
+ * neither the name of the copyright holders nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Authors: Gabe Black
+ */
+
+#ifndef __ARCH_ARM_FASTMODEL_IRIS_MEMORY_SPACES_HH__
+#define __ARCH_ARM_FASTMODEL_IRIS_MEMORY_SPACES_HH__
+
+namespace Iris
+{
+
+enum CanonicalMsn
+{
+SecureMonitorMsn = 0x1000,
+SecureMsn = 0x1000,
+GuestMsn = 0x1001,
+NormalMsn = 0x1001,
+NsHypMsn = 0x1002,
+MemoryMsn = 0x1003,
+HypAppMsn = 0x1004,
+HostMsn = 0x1005,
+CurrentMsn = 0x10ff,
+IpaMsn = 0x1100,
+PhysicalMemorySecureMsn = 0x1200,
+PhysicalMemoryNonSecureMsn = 0x1201,
+PhysicalMemoryMsn = 0x1202
+};
+
+} // namespace Iris
+
+#endif // __ARCH_ARM_FASTMODEL_IRIS_MEMORY_SPACES_HH__
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23643
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I06a7d7db95ec1ce65945c9e09f812f0b69aaa8e6
Gerrit-Change-Number: 23643
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
