Briefly, when a process opens my driver device special file, it can request certain optional services to be performed, whenever that particular descriptor call goes to the driver. These processes can stay there for long time. There is another operation (through ioctl of course) defined, which can kind of reset the card. Which means that all the open descriptors are still valid, but these process have to do login [login/out state maintained by driver] again. At this point, I have a choice, I can tell the user that any operation after that is invalid, so they have to close all the fds (and reopen them), or I can cleanup data I have attached to private area of "struct file". Now, this senario should not occur normally. But there could be a user who is not careful. So, the fds are not actually closed, in is to do with the state of driver. I was thinking that when process performs a operation on fd, kernel know to send it to correct driver. There may be a list which will let me go through all the fds associated with the driver. Usman --- Greg KH <greg@xxxxxxxxx> wrote: > On Tue, Nov 30, 2004 at 03:40:06PM -0800, Usman S. Ansari wrote: > > In this particular situation, I would like to do some cleanup, > > without too much overhead. > > What is the "situation"? Why does the driver care about this? All > other drivers do not, right? > > > What I mean, there could be a situation in which we will tell our > > customer that "this senario can result in unpredictable results". > > What is the senario? > > > Therefore I do not want to go through (nor I have time) to make a > > list, maintain a list, etc, but if such a list is already > > maintained by the kernel, than I can quickly go and do cleanup > > It's already maintained by the kernel, and cleaned up by the kernel > if userspace closes the device node, or the process goes away. > Nothing special needs to be done in the driver. > > What kind of driver are you talking about? > > thanks, > > greg k-h -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
