DragonFly kernel List (threaded) for 2007-04
Re: RFC for VKERNEL 'external' shutdown
:I'll probably start working on a little patch soon to enable 'clean'
:VKERNEL shutdown from the host system via some simple mechanism such as
:a signal handler.
:Before I dig too deeply, a couple questions:
:1) does this sound useful?
Yes, good idea.
:2) any 'gotchas' I should know about ?
: (e.g. VMSPACE / strange signal interaction)
No, it's a sound idea. The virtual kernel will get the signal.
It's probably a good idea to make it a mailbox signal on the
virtual kernel side of things rather then use a signal handler,
though, just like the other signals.
:3) thoughts on best implementation?
: I'm thinking the easiest and most 'real-system-like' would be to
: pass the same signals mentioned in init(8) directly to the in-VKERNEL
: init, which would "just work" (TM) & make things most consistant
: with a 'real system', although making TERM do a full shutdown
: might better suited to the vkernel environment (so all the
: vkernel systems don't need to fsck on boot when the host does
: a shutdown and inadvertently kills them)
:Thanks in advance,
TERM is good. It's disabled in the vkernel console code at the
moment but could be set up in a manner similar to how SIGIO is
set up in the kqueue code.
The code that checks the mailbox is in kqueue.c as well.
To discern between the SIGIO mailbox and the TERM mailbox
you probably need to direct the TERM signal to a different
mailbox address and have the kqueue code check both locations.