David,
Overkill maybe, but how else do you know that the process died and that your
driver should free resources associated with that process? Even have problem
using module reference counters in that they remain incremented if
application cores before calling close() and then you can't unload the
driver.
essentially,
your driver:Open(){ pid = current->pid. current is the current processes
task_struct from which we fetch the pid. This is pid of application opening
the driver. Build a linked list of pids added on open() and removed on
close().}
your janitor thread:
{
struct task_struct *pTs;
pPids = OurPidList;
while (pPids)
{
pTs = find_task_struct_by_pid(pPids->pid); /* A hashed lookup by
pid. */
if (!pTs)
RemoveOurDriverResourcesSinceProcessGone(pPids->pResourceInfo).
:
pPids=pPids->pNext;
}
}
Stuart
----- Original Message -----
From: "David Stroupe" <dstroupe@keyed-upsoftware.com>
To: "kernelnewbies" <kernelnewbies@nl.linux.org>
Sent: Friday, March 08, 2002 4:03 PM
Subject: Re:Driver Robustness
> >>I have written a driver for a data acqusition board. That having been
> >> completed, I am adding supporting user space code in the form of C++
> >> classes and such. During this development, I find errors in my user
> >> space code that causes a crash (null pointer and such). When this
> >> happens, the driver is still running fine, but sometimes claims that it
> >> can not be removed because it still thinks that the crashed app is
using
> >> it. (I assume that the driver is still ok because I can start a new
> >> application and talk to the driver and board) What is the appropriate
> >> way to resolve this issue at the driver level? I don't have any
> >> specific "uses counter" in my driver that is being incremented, so
> >> how/why does the driver think that it is busy? My ultimate goal is to
> >> make the driver bullet proof so that a reboot is never necessary to
> >> resolve whatever a user may try to do from a wayward application. Any
> >> driver level advice on these issues would be greatly appreciated.
> >>
> >> Just a thought:
>
> >Why not grab the PID of the application context upon an open... and save
it.
> >When your driver starts up create a kernel thread and have
> >this "janitor" thread run each 5..10 seconds that runs through the list
of
> >saved PID's and scans the current process list and if the PID is not
found,
> >terminates the driver/device resources associated with that PID. You
might
> >have to check for children of that PID too.
>
> >Stuart
>
> That's a good idea Stuart, seems like overkill tho...like I am not doing
> something else right. What is it that the driver sees that associates
> the driver with a particular PID? On this driver, there may be up to 32
> different threads requesting information or waiting for blocked I/O.
> Within the driver, how would I enumerate them?
>
> --
> Best regards,
> David Stroupe
> Keyed-Up Software
> 5307 Faireast Court
> Arlington, Texas 76018-1683
> 817/557-4903 voice
> 817/472-0408 fax
>
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
