On 10/19/2015 01:05 PM, Hans Verkuil wrote:
On 10/12/2015 06:44 PM, Mauro Carvalho Chehab wrote:
Rename the userspace types from MEDIA_ENT_T_ to MEDIA_ENT_F_ and add the backward compatibility bits.
The changes at the .c files was generated by the following coccinelle script:
@@ @@ -MEDIA_ENT_T_UNKNOWN +MEDIA_ENT_F_UNKNOWN @@ @@ -MEDIA_ENT_T_DVB_BASE +MEDIA_ENT_F_DVB_BASE @@ @@ -MEDIA_ENT_T_V4L2_BASE +MEDIA_ENT_F_V4L2_BASE @@ @@ -MEDIA_ENT_T_V4L2_SUBDEV_BASE +MEDIA_ENT_F_V4L2_SUBDEV_BASE @@ @@ -MEDIA_ENT_T_CONNECTOR_BASE +MEDIA_ENT_F_CONNECTOR_BASE @@ @@ -MEDIA_ENT_T_V4L2_VIDEO +MEDIA_ENT_F_IO
I have to agree with a comment from Shuah that F_IO is too generic. Why not keep it V4L2_VIDEO? Especially since it remains specific for video IO (VBI and SWRADIO still have their own 'function' define).
Never mind, see my comment at the end of this mail.
I might be missing something. I believe I suggested using F_IO, but I think Shuah is right and that that wasn't a good idea.
Shuah's comment from the 'Topics for workshop' thread:
- ENT_F_IO appears to be too generic, requiring additional steps to determine what kind of IO function it is really is. I propose preserving and allowing enough uniqueness to enable drivers to tag the functions when they create them. For example, if AUDIO functions are all tagged ENT_F_IO, bridge driver has to determine what kind of IO it really is. This requires finding the Interface entity associated with the function entity or comparing entity name strings. Instead, if a function can be tagged as Audio Capture when it gets created, these additional steps aren't necessary.
Regards,
Hans
@@ @@ -MEDIA_ENT_T_V4L2_VBI +MEDIA_ENT_F_V4L2_VBI @@ @@ -MEDIA_ENT_T_V4L2_SWRADIO +MEDIA_ENT_F_V4L2_SWRADIO
This text from the commit log of this patch is wrong if I understand it correctly: T_V4L2_VBI/SWRADIO are both replaced by ENT_F_IO and not by F_V4L2_VBI/SWRADIO, right?
So that log text confused the hell out of me :-)
That said, I think it is good to discuss this a bit more since we're all at the workshop anyway. The idea has always been that one entity can support multiple functions (even though we don't do that today). If we support more than one function, then we can use that to specify which type of IO the entity supports. Or we go back to the original idea of F_IO_VIDEO, F_IO_AUDIO, F_IO_VBI, F_IO_SWRADIO.
Yes, I know I wanted just F_IO, but I think Shuah has a point here.
Regards,
Hans