On Fri, Jul 26, 2024 at 06:39:27PM +0100, Mark Brown wrote: > On Fri, Jul 26, 2024 at 05:14:01PM +0100, Dave Martin wrote: > > On Thu, Jul 25, 2024 at 07:11:41PM +0100, Mark Brown wrote: > > > > That'd have to be a variably sized structure with pairs of sysreg > > > ID/value items in it I think which would be a bit of a pain to implement > > > but doable. The per-record header is 64 bits, we'd get maximal saving > > > by allocating a byte for the IDs. > > > Or possibly the regs could be identified positionally, avoiding the > > need for IDs. Space would be at a premium, and we would have to think > > carefully about what should and should not be allowed in there. > > Yes, though that would mean if we had to generate any register in there > we'd always have to generate at least as many entries as whatever number > it got assigned which depending on how much optionality ends up getting > used might be unfortunate.
Ack, though it's only 150 bytes or so at most, so just zeroing it all (or as much as we know about) doesn't feel like a big cost. It depends how determined we are to squeeze the most out of the remaining space. > > > It would be very unfortunate timing to start gating things on such a > > > change though (I'm particularly worried about GCS here, at this point > > > the kernel changes are blocking the entire ecosystem). > > > For GCS, I wonder whether it should be made a strictly opt-in feature: > > i.e., if you use it then you must tolerate large sigframes, and if it > > is turned off then its state is neither dumped nor restored. Since GCS > > requires an explict prctl to turn it on, the mechanism seems partly > > there already in your series. > > Yeah, that's what the current code does actually. In any case it's not > just a single register - there's also the GCS mode in there. Agreed -- I'll ping the GCS series, but this sounds like a reasonable starting point. Cheers ---Dave
