On Tue, 28 Nov 2023 at 20:31, Palmer Dabbelt <pal...@dabbelt.com> wrote: > > 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.
Thank you for the follow-up on this, as I had the original conversation with Jeff in passing. We (and the Alibaba folks and the BeagleV-AHEAD community) would prefer to get 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 expect real-world users, including the BeagleV-AHEAD community, to need support for the foreseeable future. Keeping it until it ends up untested (and test cases are reasonably clean) sounds like a good threshold to ensure the integrity of the codebase while giving this a clear path to stay in for its useful life. Philipp. > * 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.
