On Sun, Mar 12, 2023 at 03:37:39PM +0000, Marc Zyngier wrote: > Mark Brown <broonie@xxxxxxxxxx> wrote: > > On Sun, Mar 12, 2023 at 10:29:11AM +0000, Marc Zyngier wrote: > > > Mark Brown <broonie@xxxxxxxxxx> wrote: > > combination just for the sake of it. It's one of those areas > > where it's hard to determine if there's an intent behind the > > implementation choices made or if they're just whatever someone > > happened to write and not particularly important or desired. > It *is* desired. We've had cases of flags being reset at the wrong > time and leading to issues that would be detected by this test. The > PMU stuff is indeed one example, but similar things could happen > between SVE+MTE, for example. I take it you mean that the current situation where it's only covering X and X+PMU cases is not desired and wasn't intentional? > > > A good first step would be to be able to build these combinations > > > dynamically, and only then add new sublists to the mix. > > That would certainly be a good idea, if we were heading in that > > direction I'd also expect negative tests checking that for > > example pointer authentication registers don't appear when that's > > not enabled. I'm not sure that it's worth blocking all new > > coverage for that though, there is still value in having a bit of > > basic coverage even if not all the combinations are covered yet. > Then where is the incentive to get it fixed? People will just keep > piling stuff, and the coverage will increasingly become worse. It's always possible someone will be interested and keep plugging away at improving things over the longer term even without having other work blocked. Sometimes someone will come along explicitly trying to improve whatever the thing is, or someone other than the person submitting a given patch might see the idea being mentioned and be inspired to implement it (that process is how we ended up with the ALSA pcm-test program). The flip side of this approach is that it's encouraging people to do the minimum possible in order to reduce the chances that out of scope cleanup work gets added on to whatever they were originally trying to do, and to avoid doing smaller cleanups if they notice anything else that could be improved (especially if those things might resuling in something that'd tie up something more urgent). It's not a big deal if it's a small bit of extra work, but the more work it is than the original thing the more of an impact it can have. It's a balancing thing - sometimes things do need some push to get things done, but on the other hand if it's the only approach taken then it can become a bit of a self fulfilling prophecy. > We have to do it as some point, and now is as good a time as any. Well, I was just doing a drive by patch here because I noticed that MTE wasn't covered, it's not like I'm even looking at MTE. Realistically I'm not sure how long it'll be before I have the bandwidth for reworking this. There is some other work where I'd get blocked on it, but it's not going to be this release cycle.
Attachment:
signature.asc
Description: PGP signature
