>So I think it's reasonable to use keventd as `kinit', if you like.
>Something which knows how to launch and reap kernel daemons, and
>which provides a known environment to them.
>
>A kernel API function (`kernel_daemon'?) which does all this
>boilerplate is needed, I think.
>
I completely agree.
So I think it's reasonable to use keventd as `kinit', if you like.
Something which knows how to launch and reap kernel daemons, and
which provides a known environment to them.
A kernel API function (`kernel_daemon'?) which does all this
boilerplate is needed, I think.
I completely agree. I'll
Martin Frey wrote:
>
> >> - When started during boot (low PID (9)) It becomes a zombie
> >> - When started from a process that quits after sending the ioctl,
> >>it is correctly "garbage collected".
> >> - When started from a process that stays around, it becomes
> >>a zombie too
>
>
>> - When started during boot (low PID (9)) It becomes a zombie
>> - When started from a process that quits after sending the ioctl,
>>it is correctly "garbage collected".
>> - When started from a process that stays around, it becomes
>>a zombie too
>Take a look at
Benjamin Herrenschmidt wrote:
>
> >daemonize() makes calls that are all protected with the
> >big kernel lock in do_exit(). All usages of daemonize have
> >the big kernel lock held. So I guess it just needs it.
> >
> >Please let me know whether you have success if it makes
> >a difference with
>daemonize() makes calls that are all protected with the
>big kernel lock in do_exit(). All usages of daemonize have
>the big kernel lock held. So I guess it just needs it.
>
>Please let me know whether you have success if it makes
>a difference with having it held.
With a bit more experiments,
>>The stuff done in daemonize() and the exit_files could need
>>the kernel lock. At least on some 2.2.x version it does,
>>I did not check whether it is still needed on 2.4.
>
>Well, I don't really plan to backport this to 2.2.x. I'll
>try to see if my problem is related to the lack of kernel
>The stuff done in daemonize() and the exit_files could need
>the kernel lock. At least on some 2.2.x version it does,
>I did not check whether it is still needed on 2.4.
Well, I don't really plan to backport this to 2.2.x. I'll
try to see if my problem is related to the lack of kernel
lock, or
Hi,
>> http://www.scs.ch/~frey/linux/kernelthreads.html
>Could you explain me a bit why you need the lock_kernel ? My probe
>thread is already protected by some atomic ops, but I'm considering
>changing them to semaphores. Is there any need for the bkl to be taken
>when calling daemonize or is
>Have a look at:
>http://www.scs.ch/~frey/linux/kernelthreads.html
>I have an example there that starts and stops kernel threads
>from init_module and never produced a zombie.
>I use the same code also to start threads from ioctl and it
>works for me. I tested it on UP and SMP, Intel and Alpha,
Hi,
>How do I force a kernel thread to always be a child of init and never
>become a zombie ?
>
>I do call daemonize at the beginning of the thread (as it won't do
>anything with files, signals or whatever), but that doesn't
>seem to be enough.
>
Have a look at:
Hi,
How do I force a kernel thread to always be a child of init and never
become a zombie ?
I do call daemonize at the beginning of the thread (as it won't do
anything with files, signals or whatever), but that doesn't
seem to be enough.
Have a look at:
Have a look at:
http://www.scs.ch/~frey/linux/kernelthreads.html
I have an example there that starts and stops kernel threads
from init_module and never produced a zombie.
I use the same code also to start threads from ioctl and it
works for me. I tested it on UP and SMP, Intel and Alpha,
2.2.18
Hi,
http://www.scs.ch/~frey/linux/kernelthreads.html
Could you explain me a bit why you need the lock_kernel ? My probe
thread is already protected by some atomic ops, but I'm considering
changing them to semaphores. Is there any need for the bkl to be taken
when calling daemonize or is this
The stuff done in daemonize() and the exit_files could need
the kernel lock. At least on some 2.2.x version it does,
I did not check whether it is still needed on 2.4.
Well, I don't really plan to backport this to 2.2.x. I'll
try to see if my problem is related to the lack of kernel
lock, or
daemonize() makes calls that are all protected with the
big kernel lock in do_exit(). All usages of daemonize have
the big kernel lock held. So I guess it just needs it.
Please let me know whether you have success if it makes
a difference with having it held.
With a bit more experiments, I have
Benjamin Herrenschmidt wrote:
daemonize() makes calls that are all protected with the
big kernel lock in do_exit(). All usages of daemonize have
the big kernel lock held. So I guess it just needs it.
Please let me know whether you have success if it makes
a difference with having it
Martin Frey wrote:
- When started during boot (low PID (9)) It becomes a zombie
- When started from a process that quits after sending the ioctl,
it is correctly "garbage collected".
- When started from a process that stays around, it becomes
a zombie too
Take a look at
18 matches
Mail list logo
