Re: kernel threads and close method in a device driver

[Marty Leisner]

I ment to send this correspondence to the list.
It seems to be working much better now -- but is this
CLONE_FILES flag correct?

Is there a device to look at which does a kernel_thread on open,
and kills the thread on close (I'd like to see an example).

Thanks for the help...

Marty

- ------- Forwarded Message

To: Andi Kleen <[e-mail]>
Subject: Re: kernel threads and close method in a device driver 
In-Reply-To: Your message of "Tue, 17 Apr 2001 23:43:39 +0200."
             <[e-mail]> 
Date: Wed, 18 Apr 2001 10:49:04 -0400
From: "Marty Leisner" <[e-mail]>

In message <[e-mail]>,   you write:
>On Tue, Apr 17, 2001 at 05:04:28PM -0400, Marty Leisner wrote:
>> 	open device
>> 	do IOCTL (spinning a kernel thread and doing initialization)
>> 
>> There is currently an IOCTL which short-circuits to the close method.
>> Turns out it seems necessary to do this IOCTL -- close never gets 
>> invoked.
>
>Call daemonize() in the kernel thread.
>
>-Andi

It seemed like daemonize was a good idea (after thinking about it,
it makes a lot of sense...there are multiple instances of the file
open...[I'm not used to opening files NOT in user space ;-))]

daemonize wasn't in 2.2.12 (I copied it from 2.2.18):

static void daemonize(void)
{  
        struct fs_struct *fs;

        /*
         * If we were started as result of loading a module, close all of the
         * user space pages.  We don't need them, and if we didn't close them
         * they would be locked into memory.
         */                
        printk("want to daemonize");
        exit_mm(current);

        current->session = 1;
        current->pgrp = 1;

        /* Become as one with the init task */

        exit_fs(current);       /* current->fs->count--; */
        fs = init_task.fs;
        current->fs = fs;
        atomic_inc(&fs->count);
}

This seems reasonable, get rid of your files and inherit init's

However, 
:1 mleisner@piquin; lsof -p 630
COMMAND   PID     USER   FD   TYPE DEVICE SIZE NODE NAME
aicCtrlTh 630 mleisner  cwd    DIR    3,1 1024    2 /
aicCtrlTh 630 mleisner  rtd    DIR    3,1 1024    2 /
aicCtrlTh 630 mleisner    0u   CHR  136,0         2 /dev/pts/0
aicCtrlTh 630 mleisner    1u   CHR  136,0         2 /dev/pts/0
aicCtrlTh 630 mleisner    2u   CHR  136,0         2 /dev/pts/0
aicCtrlTh 630 mleisner    3u   CHR   43,0      8034 /dev/aicdrv

which is the original file handles from the application...

Any hints?  I played around with the CLONE_FILES flag on thread_creation,
and at least now I can get through to close (I have to look at the thread kill strategy).

But now I have (after an open, create thread, close cycle)
bash3 :3 mleisner@piquin; lsof -p 584
COMMAND   PID     USER   FD   TYPE DEVICE SIZE NODE NAME
aicCtrlTh 584 mleisner  cwd    DIR    3,1 1024    2 /
aicCtrlTh 584 mleisner  rtd    DIR    3,1 1024    2 /
aicCtrlTh 584 mleisner    0u   CHR  136,0         2 /dev/pts/0
aicCtrlTh 584 mleisner    1u   CHR  136,0         2 /dev/pts/0
aicCtrlTh 584 mleisner    2u   CHR  136,0         2 /dev/pts/0
bash3 :3 mleisner@piquin; lsmod
Module                  Size  Used by
aicdrv                 18104   0 
nfs                    29656   1  (autoclean)
nfsd                  144060   8  (autoclean)
lockd                  30984   1  (autoclean) [nfs nfsd]
sunrpc                 52516   1  (autoclean) [nfs nfsd lockd]
fa311                   4404   1  (autoclean)

marty
[e-mail]

- ------- End of Forwarded Message