On Jul 30, 11:42am, charles.cui1...@gmail.com (Charles Cui) wrote: -- Subject: Re: updates?
| Yes, it works for me, each time I send you a new patch, I will compile my | kernel and userland, | and testing using the program we have written. | | Here is a short video that I created from my environment which shows the | real time signal works for me | https://www.dropbox.com/s/amds3jmpfev8jz9/realtime_signal.mov?dl=0 | | Also, I looked at all files needed in the real time signal patches, | and attached all files of them, you can replace using these files and see | whether there are any | differences with the current settings. | | /usr/src/sys/sys/signal.h | | /usr/src/include/limits.h | | /usr/src/lib/libc/gen/sysconf.c | | /usr/src/sys/kern/kern_sig.c | | /usr/src/sys/kern/sys_sig.c | | /usr/src/sys/sys/signalvar.h | | /usr/src/sys/sys/unistd.h | | 2016-07-30 9:36 GMT-07:00 Christos Zoulas <chris...@zoulas.com>: There are two issues with the code that I found and I have everything working now. It is not enough to test with the test program (which works); for example as I mentioned before, booting with a kernel that has all your patches fails on sshd (you can't login remotely) and an interrupted make does not work properly. If you want I can show you what's wrong with the changes, but I think it is better if you find the problems yourself. The idea here is to make sure that the code works exactly like before in the absense of real-time signals, which is not the case currently. Both bugs are in kern_sig.c. One of them is the critical one that breaks signal delivery, the other is more of a clarification of what happens when we want to maintain the pending signal mask. Best, christos
