On Sat, Feb 22, 2014 at 2:04 PM, Antti Kantee <[email protected]> wrote: > 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.
Couldnt find anything. > For example, I have timer support in my local tree (I thought I > mentioned it to you on irc). I assumed option 2 "leave things as they currently are" meant "as they are in the tree", ie you were not happy with the semantics enough to add anything. > 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. SIGSYS is optional under Posix so host might not have it. Could be useful though for debugging. Justin ------------------------------------------------------------------------------ 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
