在2024年7月15日七月 下午8:15，Maciej W. Rozycki写道： [..] > I don't know what prctl(2) has to do with this. If you don't implement > this part, then your change will cause Linux to behave inconsistently and > therefore I'll have to NAK it. I think your concern was regarding user space application needs to set NaN2008 bits at runtime? In this case, the best interface to inform kernel about NaN2008 changes is prctl. I may misinterpret your comments. > > It's not much to do anyway, as I have prepared `ptrace_setfcr31' already > to handle masking correctly, so all you have to do is to set the mask as > required for the right thing to happen. I shouldn't have needed to point > you at it though, as that code is easy to find. I think I got your point, will try to implement it. > >> We are unable to prevent user applications write NAN2008 bits for the "switchable >> QEMU" as well. So I'd perfer leave it as is, and let this feature go into 6.11 so people >> can start to use it. > > This doesn't matter either, as your change only addresses the case where > FCSR.NAN2008 isn't writable anyway, which is the sole reason you want to > switch between native hard float support and emulation, doesn't it? > > In fact where FCSR.NAN2008 is writable your new mode has to be equivalent > to "ieee754=strict", because then there is no need to trigger emulation > for either NaN mode. Please do verify that this is the case. This had been verified with perf math-emu counters to ensure no unnecessary emulation is triggered. > >> This is actually a request from Debian MIPS team so they can get glibc tests run on >> mismatched NaN hardware. > > That doesn't matter for us here (and I have a bad suspicion anyway), but > the Debian team is of course free to do what they want here, the GNU GPL > applies. We care about our downstream users, don't we? There are some lags on Debian buildd queue for mips64el due to lack of high performance hardware with huge memory. They were about to source some Loongson 3A4000, which is NaN2008 only. But many packages test cases are failing on it due to NaN2008. They asked me to help and that was my solution. I sincerely want to get this change upstreamed to cover some downstream use cases. I don't know what theory do you have here, but that's all stories behind. > > And also they can always use the "nofpu" kernel parameter to run their > verification. I used it for mine back at ImgTec before 2008 NaN hardware > was available, also to verify emulation, which I wrote too. Perhaps that > is also the right solution for Debian actually? I'll suggest to them, thanks. > > Maciej -- - Jiaxun
