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 <[EMAIL PROTECTED]>
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."
<[EMAIL PROTECTED]>
Date: Wed, 18 Apr 2001 10:49:04 -0400
From: "Marty Leisner" <[EMAIL PROTECTED]>
In message <[EMAIL PROTECTED]>, 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
[EMAIL PROTECTED]
- ------- End of Forwarded Message
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
