On Wed, 22 Nov 2023 14:27:50 PST (-0800), jeffreya...@gmail.com wrote:
...
[Trimming everything else, as this is a big change. I'm also making it
a new subject/thread, so folks can see.]
More generally, I think I need to soften my prior statement about
deferring this to gcc-15. This code was submitted in time for the
gcc-14 deadline, so it should be evaluated just like we do anything else
that makes the deadline. There are various criteria we use to evaluate
if something should get integrated and we should just work through this
series like we always do and not treat it specially in any way.
We talked about this some in the pachwork meeting today. There's a lot
of moving parts here, so here's my best bet at summarizing
It seems like folks broadly agree: I think the only reason everyone was
so quick to defer to 15 was because we though the Vrull guys even want
to, but sounds like there's some interest in getting this into 14.
That's obviously a risky thing to do given it was sent right at the end
of the window, but it meets the rules.
Folks in the call seemed generally amenable to at least trying for 14,
so unless anyone's opposed on the lists it seems like the way to go.
IIRC we ended up with the following TODO list:
* Make sure this doesn't regress on the targets we already support.
From the sounds of things there's been test suite runs that look fine,
so hopefully that's all manageable. Christoph said he'd send
something out, we've had a bunch of test skew so there might be a bit
lurking but it should be generally manageable.
* We agree on some sort of support lifecycle. There seemed to be
basically two proposals: merge for 14 with the aim of quickly
deperecating it (maybe even for 15), or merge for 14 with the aim of
keeping it until it ends up un-tested (ie, requiring test results are
published for every release).
* We actually find some time to sit down and do the code review.
That'll be a chunk of work and time is tight since most of us are
focusing on V-1.0, but hopefully we've got time to fit things in.
* There's some options for testing without hardware: QEMU dropped
support for V-0.7.1 a while ago, but there's a patch set that's not
yet on the lists to bring that back.
So I think unless anyone's opposed, we can at least start looking into
getting this into GCC-14 -- there's obviously still a ton of review work
to do and we might find something problematic, but we won't know until
we actually sit down and do the reviews.
---
Then for my opinions:
The only policy worry I have is the support lifecycle: IMO merging
something we're going to quickly deprecate is going to lead to headaches
for users, so we should only merge this if we're going to plan on
supporting it for the life of the hardware. That's always hard to
define, but we talked through the option of pushing this onto the users:
we'd require test results published for every GCC release, and if no
reasonably cleas test results are published then we'll assume the HW is
defunct and support for it can be deprecated. That's sort of patterned
on how glibc documents deprecating ports.
IIRC we didn't really end up with any deprecation policy when merging
the other vendor support, so I'd argue we should just make that the
general plan for supporting vendor extensions. It pushes a little more
work to the vendors/users than we have before, but I think it's a good
balance. It's also a pretty easy policy for vendors to understand: if
they want their custom stuff supported, they need to demonstrate it
works.
