Hi Gabe,
I think you've interpreted everything correctly. I think the only context
you're missing is that we're planning to change the regressions such that
there is no dependence on proprietary binaries. This will allow all
users/developers to run the regressions before committing code. We haven't
made any progress in this direction, yet. We've just talked about it.
I think the biggest implication of this is that we'd drop the SPARC full
system tests completely. This also means we'd drop the EIO tests (which I
think we already have).
Slightly off topic:
One of my biggest gripes with the current regressions is that it is
incredibly hard for a user or a developer who commits code every once in a
while to run and understand the regression output. It's a good step for you
to be able to find the fishy stats changes and pin them to a commit, but I
really wish it was easier for our users to do that themselves.
Cheers,
Jason
On Sat, Apr 1, 2017 at 6:27 AM Gabe Black <gabebl...@google.com> wrote:
> Hi folks. I'm working through the nightly regressions to get them to a good
> point for a rebase of our internal branch of gem5, and I've noticed a few
> things:
>
> 1. The stats have been changed but not updated a bunch of times. I've
> identified almost all the points this has happened since the references
> were last updated, and have patches which fix them. Some stat changes are a
> little fishy, but I'll at least identify the guilty change(s) so that their
> authors can look them over.
> 2. The SPARC FS regression were just plain not running because its
> configuration had been broken. I'll have a patch to fix this.
> 3. The nightly regressions are still checking gem5 out from mercurial.
> 4. The "encumbered" repository has, as far as I can tell, not be converted
> from mercurial to git. Probably this isn't a problem because this code is
> mostly unchanging and becoming less relevant over time, especially since
> EIO support was removed from the process classes (it was, right?).
> 5. The EIO code is also broken, because it tries to call "fatal" with a
> "(void)" cast in front of it in a ternary operation. Something like "foo ?
> (void)fatal("a bad thing happened") : (void)fatal("a different bad thing
> happened")". What "fatal" expands to now is apparently not compatible with
> this usage. Since I can access the encumbered repository, I can attempt to
> fix this.
>
> I can (and in at least in some cases will) fix most of these issues, except
> maybe 4 if we still want encumbered to exist. Please speak up if I've
> misinterpreted something or am missing some important bit of context.
>
> Gabe
> _______________________________________________
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
