good day. i'v took a look at the patch:
https://github.com/rsc/plan9/commit/3715bf9b86a86ed6a3a857cabfc7dff5d70b409b i spend some time yesterday trying to implement the same behaviour in 9front kernels and it is not too difficult, but the semantics would need to be clarified and i'm not totally convinced this is the right approach. one issue i can see with this is that now it is unclear what /proc/$pid/fpregs is supposed to be once a process executes the note handler. as i understand the patch above, fpregs would reflect the registers before executing the handler, not the one being in use. was this intended? i think this could lead to confusion if code uses vector instructions and the debugger doent reflect the actual register state of whats being executed. maybe the solution could be to have 2 register files then: fpregs <- current execution ofpregs <- saved at trap/note also, do we want the note-handler to have a clean (FPinit) fpu context or should it get a copy? and why? do we want to backport this to all architectures, or just the ones that combine fp and vector instructions? it would be a good idea to document this changes of behaviour somewhere and have a rationale. and last: have the go developers considered alternatives such as NSAVE/NRSTR for their "signal" handling? -- cinap ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Taf6b900592afc500-M3ba57043ade5e1039c47ffe3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
