> >> (2) the increment of the variable vfl->users is incoherent with the > >> decrement of the same variable in the function video_release(). > >> A brief analysis of the source code and of the patch reveals > >> that it is so, but i will not enter into details. > > > Please go into details, IMHO the current code is fine. > > The fact is that I am writing a driver for my webcam. > So I thought to use the field "users" of the struct video_device* > to keep track of the number of users that are accessing to the > V4L device at a time. Yes. videodev does that for drivers which use the "old" interface. > For some reasons some problems occurred with that counter after a > series of open and release calls (using the new interface), For the new interface the users variable isn't touched by videodev (and the v4l driver shouldn't do that too as it is gone in 2.5.x ...). > I found that in the function video_open() a vfl->users++ instruction > is never reached, in case of success of the > file->f_op->open(inode,file) call. Yes. > On the contrary, vfl->users is always decremented in video_release() > using both the new and the old interface. No. When using the new interface video_release() never is called. video_open swaps file->f_op, thus file->f_op->release doesn't point to video_release() but to your drivers release function. > Therefore vfl->users can assume negative values... It can't. In fact it should always be zero for "new interface" drivers. Gerd -- You can't please everybody. And usually if you _try_ to please everybody, the end result is one big mess. -- Linus Torvalds, 2002-04-20
