Thank you for your answer. > I believe that /proc/$pid/regs is the note registers during > the note handler, and so .../fpregs should be the same. I don't think we > need fpregs and ofpregs, since we don't have regs and oregs.
I think that is mistaken. /proc/n/regs gives you the registers of the process when it entered kernel mode (Porc.dbgreg) regardless of if the process is currently executing a note handler or not. Which makes alot of sense, as this is the basis for the debugger to work (you place BRK instructions and the process traps from usermdoe to kernel, saves the user registers in Proc.dbgreg and wakes the debugger to take a look). The original user registers before we enter the note handler are actually copied to the user-mode stack (by notify), and the kernel remembers a pointer to it (Proc.ureg) for later when the handler does noted() syscall. In summary, we have: Proc.dbgreg <- pointer to Ureg on the kernel stack (for debugger) Proc.ureg <- pointer to saved Ureg on user stack (for noted) Also, the user-process is free to modify the registers before calling noted(). 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. > It would make sense to me to allow on all architectures for consistency, > but I'm personally working on this as a Go developer, not a Plan 9 > developer. I'm just trying to minimize the irregularities that Go takes on > to support Plan 9. That was mainly why i was asking about a rationale. Who wants to touch for example the MIPS fpu enumation code for this? The real motivation here is really the integer vector instructions. Lets make that explicit. As you said, the 9front kernel does a similar with within the kernel itself for amd64 and arm64 allowing the use of vector instrictions even from interrupt handlers. Tho this change was much easier todo it is not visible to the userspace impact. >> also, do we want the note-handler to have a clean (FPinit) fpu >> context or should it get a copy? and why? > I chose to give it a copy because systems might initialize certain > registers to certain values at startup and then assume those are always > set. Copying preserves those decisions. The integer registers are also > copied. To me it fits with the simple elegance of fork compared to the > awkwardness of StartProcess. (Other operating system designers may > disagree, but Plan 9 is a system in the fork camp.) ok, fair enougth. >> such as NSAVE/NRSTR for their "signal" handling? > I've never worked on the Plan 9 port of Go before, so I can't speak for > the port's developers did, but I had completely forgotten NSAVE/NRSTR > existed. I just looked at them anew, and I don't think they would help. > noted(NRSTR) puts the onus of saving registers on the user process, which > is maybe not great but fine for the CPU registers in the ureg struct, but > the FPU registers aren't there. Yes, it allows you to handle the saving logic from usermode and lets you have also re-entrant handlers (this was for emulating unix signals). > You'd need to make a separate space for them, and then worry about all the > nuances of different FP save routines on > different systems, detecting whether they need to be saved at all, and so > on. Well, your compiler emits simd instructions already, all you'd need is to wrap your handler with some code that saves the registers and restores them afterwards. You already know what registers your generated code is going to use. no? > The kernel already has to get all that code right for context switches. > Getting it right for note handlers seems like a reasonably small expansion > of that role. Other operating systems do that just fine. Sure, you need to reserve some space eigther in the kernel, or in userspace. Note also that shoving another FPsave struct into the Proc structure increases its size by ~1K. So everyone pays that price for go programs using simd in note handlers. (Tho this can be avoided). > And as I noted (ha!) earlier, this change benefits C as much as it benefits > Go. Yes please, that is what i found missing in all these go bug reports and commit messages. There needed to be a discussion about the pros and cons and some convincing. 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. -- cinap ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Taf6b900592afc500-M50476cb6a8468035fa4eb478 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
