On Monday, January 03, 2011 20:35:41 David Ellingsworth wrote: > Why does this matter? From my understanding, v4l2_fh is meant to be > embed it in a device specific structure. No, v4l2_fh is a per-filehandle structure, not a per-device node structure. filp->private_data is meant to store per-filehandle data (such as v4l2_fh), but instead it stores per-device node data (struct video_device). And that prevents it from being used to store struct v4l2_fh. And there is a perfectly valid alternative for this in the form of video_drvdata which does not use filp->private_data and so makes it available for v4l2_fh. Regards, Hans > If it is the first member in > the device specific structure, then the pointer to v4l2_fh is the same > as the one to the device specific structure. Otherwise, a simple > container_of can be used to calculate the appropriate address of the > container. In either case, the pointer calculation method is always > going to be faster than executing a call, and de-referencing multiple > pointers to retrieve the same information. filp->private data is there > for a reason, why not use it as intended and avoid the additional > overhead added by this patch? > > Regards, > > David Ellingsworth > -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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
