On 21/02/14 22:28, Justin Cormack wrote: >> First of all, there are several signal "models" that you can select for >> a rump kernel by calling rump_boot_setsigmodel(): panic, ignore, record >> and raise. The first three are hopefully obvious (if not, see >> src/sys/rump/librump/rumpkern/signals.c). I'm talking about the last >> one (raise), which is also the default model. >> >> A signal can be delivered either to a local client or a remote client. >> The signal is raised in the host container (if available). On POSIX >> hosts it's simply raise(), and called either via rumpuser_kill() or the >> RUMPSP_RAISE PDU for local or remote clients, respectively. This is >> what works and happen by default. It's not very many lines of code >> (~10'ish). >> >> As I mentioned in the previous mail, the other part is tracking signal >> masks per rump kernel process (well, thread) context and interrupting >> syscalls when a signal is delivered (iff the syscall is interruptable). >> This is what doesn't work and would be quite a few lines of code. >> >> I think I originally implemented the "raise" signal model so that >> SIGXFSZ from a file system could be tested. Even with several years of >> hindsight, I'm not sure if implementing it was a mistake, pretty much >> confirming that deciding what "the right thing to do" is not easy here. > > That seems like a fairly weak justification. I am becoming more > inclined to go for option 3 now... If there are no syscalls that > generate signals (itimer etc) and its all there just for SIGXFSZ which > is not really needed as a signal, then its just much simpler to remove > it all. None of these generated signals dont also have perfect;y good > return codes if the signal is not delivered.
I'm not sure how the original motivation leads to suspect that there is nothing else generating signals now. For example, I have timer support in my local tree (I thought I mentioned it to you on irc). Also, I'm wondering if rump_enosys() should generate SIGSYS. I can't quite remember why I left it out originally. It might be useful in cases where callers are not checking return values. ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
