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. > > 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.
Attachment:
signature.asc
Description: PGP signature
