V4L2 has multiple opens per device, and it doesn't require passing
file*s to drivers. That lets drivers remain decoupled from struct file
(which they shouldn't care about anyway), and it lets file->private_data
remain available for use by videodev.o. It's good design, and gives you
more control over the v4l system.
If you want to keep both so existing drivers still work, then you just
need to add new versions of video_register_device() and struct
video_device (and appropriate code to all the video_xxxx() functions in
videodev.c supporting both interfaces).
Bill.
Gerd Knorr wrote:
>
> Alan Cox wrote:
> > > No. videodev.o allows only one process to open the device. Any chance
> > > [ ... ]
> > Change it but keep a flag so the videode enforces it for legacy drivers for 2.4
>
> My plan is to simply pass down the struct file* instead of struct
> video_device* (except for open). The driver can simply hook per
> filedescriptor data into file->private_data then (or just the driver data
> if it doesn't want allow multiple opens and therefore doesn't need per-fd
> data). This requires changes of the driver callbacks, i.e. we need a second
> set of hooks (called open2/close2/... for example), depending on the flag
> the old/new ones are called by videodev.c.
>
> Right now there is...
>
> | int (*open)(struct video_device *, int mode);
>
> Needs a additional struct file*.
>
> | void (*close)(struct video_device *);
> | int (*ioctl)(struct video_device *, unsigned int , void *);
> | int (*mmap)(struct video_device *, const char *, unsigned long);
>
> Replace struct video_device* with struct file*.
>
> | long (*read)(struct video_device *, char *, unsigned long, int noblock);
> | long (*write)(struct video_device *, const char *, unsigned long, int noblock);
>
> Replace struct video_device* with struct file*, remove noblock (the driver
> can check file->flags). Maybe check out kiobuf (havn't looked at it yet),
> let videodev.c allocate kiobufs and pass them down to the driver.
>
> | unsigned int (*poll)(struct video_device *, struct file *, poll_table *);
>
> This could stay as-is, althrouth the struct video_device isn't required
> any more...
>
> Another minor problem is that allowing multiple opens implies some minor
> API changes. Right now a application can do anything once it has opened
> (i.e. allocated) the device. With multiple opens allowed only a few ioctls
> (basically VIDIOG*) work all the time, other ones might return -EBUSY if
> another application uses the driver in parallel. Should I care? Maybe
> allow apps to open the driver with O_EXCL like the floppy driver does?
>
> Gerd
>
> --
> Protecting the children is a good way to get a lot of adults who cant
> stand up for themselves. -- seen in some sig on /.
>
> --
> To unsubscribe: mail [EMAIL PROTECTED] with
> "unsubscribe" as the Subject.
--
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
