Hi Hans, On Monday 01 December 2008, Hans Verkuil wrote: > On Monday 01 December 2008 15:24:43 Laurent Pinchart wrote: [snip] > > In a few months time (probably even earlier) the v4l2_device > > structure will be reworked (and possible renamed). I'm fine with it > > going to linux-next now if we agree on the following. > > > > - We should only advocate v4l2_device usage for subdevices-aware > > video devices. Porting all drivers to v4l2_device is currently > > pointless and will only make future transitions more difficult. > > Agreed. For now it is only relevant for drivers that use subdevices. > > > - v4l2_device should be marked as experimental. I don't want to hear > > any API/ABI breakage argument in a few months time when the framework > > will evolve. > > Am I overlooking something? This API is a kernel API, not a public API. > Hence if I (or anyone else for that matter) make future changes then it > is my responsibility to adapt all other drivers that are affected at > the same time. I don't see how any of this could break compatibility. > Except for out-of-kernel drivers, of course. But that's the risk that > they always run. You're right. It might be useful to state that the API is a work in progress in the documentation, but I'll let you decide on that. > Marking this API as experimental seems pointless to me. It either works > and so is available for use or it doesn't and then it is a plain old > bug that needs to be fixed. I also know already that there will be > changes as e.g. sensors require a new ops category and v4l2_device > might need a notifier callback as well. However, I'm not going to > implement that until there is also a driver that uses it (adding > functionality to an internal API just because it might be needed in the > future is a really bad idea). Best regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
