> Which reminds me - Linus said he prefers to have a
>
> struct v4l_ops
> {
> int (*set_window)(....)
> int (*get_window)(..
> }
>
> type set up with one ioctl parser in the core code and sensible interfaces
> in the driver code - which fits nicely with the V4l2 proposal
The point of doing it this way being?
We already have the userspace copying in the v4l2 core code. I don't
think we can move more functionality to the core code, args checking
and stuff still needs to be handled by the driver. So we would move
from something like ...
driver_ioctl(file,cmd,arg)
{
struct file_data *fh = file->priv_data;
struct driver_data *drv = fh->driver_data;
switch (cmd) {
case VIDIO_FOO:
{
struct video_foo *f = arg;
[ ... ]
}
case VIDIO_BAR:
{
struct video_bar *b = arg;
[ ... ]
}
}
}
to alot of small functions like this:
driver_foo(file, struct video_foo *f)
{
struct file_data *fh = file->priv_data;
struct driver_data *drv = fh->driver_data;
[ ... ]
}
driver_bar(file, struct video_bar *b)
{
struct file_data *fh = file->priv_data;
struct driver_data *drv = fh->driver_data;
[ ... ]
}
I fail to see why the second is much better. The somewhat
ugly void pointer for arg is hidden in the core code, but
that's all. Is that really worth the effort?
Gerd
--
Gerd Knorr <kraxel@xxxxxxxxxxx> -- SuSE Labs, Außenstelle Berlin
