> > > Could you make a helper for open like for ioctl ?
> >
> > video_open does call video_device[minor]->fops->open(), isn't that
> > enought?
>
> I'd prefer seeing exclusive opening handeled in the helper initially.
Ok, I see what you mean. That was another issue I was thinking about.
Current videodev.c allows one open at a time only, the new code removes
that restriction (intentionally).
Should videodev.c provide a way to ask for exclusive opens to maintain
backward compatibility, using some flag in struct video_device maybe?
Is there some sane way to do this without having to hook into
fops->release? Checking inode->i_count maybe?
> > Sorry, I don't understand. What exactly do you mean?
> > file->private_data? videodev.c doesn't touch it ...
>
> But the skeleton driver you provide does so.
Thats just some sample code, a dummy driver which does nothing but print
some messages to the log. If you want allow multiple applications
access the driver at the same you need some way to disturgish the file
handles, and skeleton.c demonstrates how this can be done using
file->private_data.
usb drivers are free to do with file->private_data whatever they want
(like skeleton.c does), videodev.c doesn't use it.
Gerd
-- #define ENOCLUE 125 /* userland programmer induced race condition */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 21:00:32 EST