Hello all, Gerd Knorr wrote:
i.e. something which does kind of "fcntl(fd, F_SETFL, oldflags | O_EXCL)"? This is illegal according to the manual page, but you get the idea ...
Yes, that's exactly what I meant.
Should be easy to do, as long as this applies to _all_ ioctls. If so this can easily be catched at the top of the ioctl handler with just a few lines of code.
It's no problem if it applies to all ioctls. (I previously made a distinction between query and set type ioctls, but only for use with priority levels) Note that the ioctl which stops the O_EXCL mode should always be allowed, even if other users have opened the device. Else I'd have to close the device to get out of the excl mode, and there'd be no advantage in comparison to the earlier proposed open with O_EXCL flag. BTW are you certain it's that simple? I'd have expected you get some concurrency problems when you do only a simple check when the process enters kernel domain. Since the module is reentrant (isn't it?) a different process could open the device after you've done the check but before the "pseudo-exclusive" ioctl has been executed.
But it might have some intresting side effects. Not as long as you capture via read(), but if it is done via streaming capture (which needs ioctls). Switching to exclusive mode temporarely for tuning affects the vbi capture thread too ...
I guess you're assuming that I'd use a dup'ed file handle to do the channel switch? Well, firstly I think it'll be very rare that ioctls return EBUSY since it'd require that another process opens the device just inbetween the start of O_EXCL (the start should be refused right away if there already are other users) and the channel change ioctls. Secondly, the control process would immediately terminate the O_EXCL mode when it sees an EBUSY, so the disruption for the capture thread would only be very short. It certainly needs to be considered, but since it's very rare, even a loss of one frame's data is no problem. bye -tom
