cinap_len...@felloff.net once said: > There was never a Ureg* equivalent for the fpu state (being dumped on > the user stack). However, i believe, as the fpu is being disabled > during execution of the note handler, you could imaginge a handler > using fpregs file to read/modify the fpu state. > > So the conflict here is that we have two valid uses here. We want the > current fpu state (for debuggers) and for note handlers, we might need > to get to the saved fpu state of the interrupted program. That is why > i proposed the ofpregs file (for archs that provide a separate fpu > context for note handlers). Kind of prioritying the debugger here, as > it does not need to be aware about if the process is currently > executing in a note handler or not, it will always be the "regs" and > "fpregs" files reflecting the current state of the process. For note > handler, you'd open "ofpregs" or "fpregs" files depending on the > kernel support.
If we're going down this route, we should copy the FPsave to the stack in notify as we do the Ureg. Then we wouldn't need the ofpregs file at all. This will require some thinking about backwards compatibility. There needs to be a way to signal that you have additional data after the Ureg. "I agree that it is really sad that we have to save/restore FP on signals, but I think it's unavoidable." - torvalds, 2002 > I want to avoid another nsec() scenario where new features get hastily > introduced for go, just for go later to abandon it. Go has alot more > options here solving the problem. Anything we add to the kernel is > going to stick around forever... If we go there, lets do it properly. What did Go abandon? It looks like they're still using the nsec and tsemacquire system calls over a decade later. Did I miss something? Cheers, Anthony ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Taf6b900592afc500-M7101db7be15ad0c148f61a4e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
