kernel daemon clean up

2002-05-20 Thread Zhihui Zhang
When we reboot a machine, it seems to me that the kernel sends signal 15 to daemons and wait 60 seconds for them to finish. In my program, I use kthread_create() to create a daemon, how to make sure that my daemon finishes all its job before reboot can proceed? Do I need to let the daemon catch

Re: kernel daemon clean up

2002-05-20 Thread Doug White
On Mon, 20 May 2002, Zhihui Zhang wrote: > > When we reboot a machine, it seems to me that the kernel sends signal 15 > to daemons and wait 60 seconds for them to finish. In my program, I use > kthread_create() to create a daemon, how to make sure that my daemon > finishes all its job before rebo

Re: kernel daemon clean up

2002-05-20 Thread Alfred Perlstein
* Doug White <[EMAIL PROTECTED]> [020520 15:01] wrote: > On Mon, 20 May 2002, Zhihui Zhang wrote: > > > > > When we reboot a machine, it seems to me that the kernel sends signal 15 > > to daemons and wait 60 seconds for them to finish. In my program, I use > > kthread_create() to create a daemon,

Re: kernel daemon clean up

2002-05-20 Thread Mike Silbersack
On Mon, 20 May 2002, Alfred Perlstein wrote: > level not edge. I think you can also use the CURSIG macro to check > for pending signals if you don't want to yeild. > > -- > -Alfred Perlstein [[EMAIL PROTECTED]] Is any of this documented right now? I had a use for checking whether a kill signa

Re: kernel daemon clean up

2002-05-20 Thread Alfred Perlstein
* Mike Silbersack <[EMAIL PROTECTED]> [020520 15:15] wrote: > > On Mon, 20 May 2002, Alfred Perlstein wrote: > > > level not edge. I think you can also use the CURSIG macro to check > > for pending signals if you don't want to yeild. > > > > -- > > -Alfred Perlstein [[EMAIL PROTECTED]] > > Is

Re: kernel daemon clean up

2002-05-21 Thread Mike Silbersack
On Mon, 20 May 2002, Alfred Perlstein wrote: > * Mike Silbersack <[EMAIL PROTECTED]> [020520 15:15] wrote: > > > > Is any of this documented right now? I had a use for checking whether a > > kill signal was present for a process inside the vm system a few months > > back, but didn't believe it