>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.
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 kernel/kmod.c:call_
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 ha
>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
>>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
>loc
>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 m
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 th
>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
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:
http://www.scs.ch/~frey/linux/ker
Hi !
I'm changing the ADB bus reset & probe code to be in a kernel threads
that is created when a bus reset is triggered and that dies of it's own
death.
Everything is fine when the bus reset is triggered during kernel init as
my thread is a child of init. However, when created as a result of a
11 matches
Mail list logo
