Re: RFCv2: Media controller proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday 17 September 2009 00:28:38 Karicheri, Muralidharan wrote:
> >
> >> And as I explained above, a v4l2_subdev just implements an interface. It
> >has
> >> no relation to devices. And yes, I'm beginning to agree with you that
> >subdevice
> >> was a bad name because it suggested something that it simply isn't.
> >>
> >> That said, I also see some advantages in doing this. For statistics or
> >> histogram sub-devices you can implement a read() call to read the data
> >> instead of using ioctl. It is more flexible in that respect.
> >
> >I think this will be more flexible and will be less complex than creating a
> >proxy
> >device. For example, as you'll be directly addressing a device, you don't
> >need to
> >have any locking to avoid the risk that different threads accessing
> >different
> >sub-devices at the same time would result on a command sending to the wrong
> >device.
> >So, both kernel driver and userspace app can be simpler.
> 
> 
> Not really. User application trying to parse the output of a histogram which
> really will about 4K in size as described by Laurent. Imagine application does lot of parsing to decode the values thrown by the sysfs. Again on different platform, they can be different formats. With ioctl, each of these platforms provides api to access them and it is much simpler to use. Same for configuring IPIPE on DM355/DM365 where there are hundreds of parameters and write a lot of code in sysfs to parse each of these variables. I can see it as a nightmare for user space library or application developer.

I believe Mauro was talking about normal device nodes, not sysfs.

What is a bit more complex in Mauro's scheme is that to get hold of the right
device node needed to access a sub-device you will need to first get the
subdev's entity information from the media controller, then go to libudev to
translate major/minor numbers to an actual device path, and then open that.

On the other hand, we will have a library available to do this.

On balance I think that the kernel implementation will be more complex by
creating device nodes, although not by much, and that userspace will be
slightly simpler in the case of using the same mc filehandle in a multi-
threaded application.

Regards,

	Hans


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux