Laurent Pinchart wrote: > Hi Darren, > > thanks for taking the time to provide feedback.
No problem. > On Wednesday 15 October 2008, Darren Longhorn wrote: >> Laurent Pinchart wrote: >> >> <snip> >> >>> linux-tv.org Mercurial trees contain a copy of the whole v4l/dvb >>> subsystem. The main implication would be that, to use the latest uvcvideo >>> driver instead of the one shipped with your kernel, you will have to >>> install the v4l core module from the Mercurial tree along with the >>> uvcvideo module, instead of the uvcvideo module only as you do now. >> Could you expand on why the v4l core module would also be required? > > Mercurial trees host a copy of the whole v4l/dvb subsystem. The v4l/dvb core > is source compatible with all Linux kernels from 2.6.16 up. The device > drivers maintain backward source compatibility as well, but the first Linux > kernel version they are compatible with depends on the individual drivers' > developers. > > As a v4l/dvb tree host a backward compatible copy of the v4l core source, > drivers don't have to care about backward compatibility with older versions > of the v4l/dvb APIs. For the uvcvideo driver this would mean I can drop an > important part of the compatibility code as the driver will only have to > support the latest v4l/dvb API. To use the driver with older kernels you > would then have to use the v4l/dvb core moduels as well, as the driver itself > doesn't maintain backward compability with previous versions of the v4l/dvb > core. Thanks, that's very clear. >>> I would expect the number of SVN checkouts to have dropped over the last >>> 3 monts, but Berlios doesn't provide such statistics. I'm thus asking >>> your opinion : should I switch the Linux UVC driver to a Mercurial tree ? >>> >>> Pros: >>> - The driver will be hosted along most other video-related kernel >>> projects - An important part of the compatibility code (uvc_compat.h and >>> various #ifdef's around the source) can be dropped, as the source tree >>> contains the latest v4l core source. >> That answers my questions above, I think? I think that would be a con >> for those of use who backport to older kernels. > > Backporting will still work, but you will have to backport the v4l/dvb core > as > well. Sure. > Do you really mean backporting (thus on kernels older than 2.6.15, as the > uvcvideo driver supports 2.6.15+ kernels already), or were you referring to > using the driver with a 2.6.15+ kernel ? In the later case the switch to > Mercurial would drop compatibility with 2.6.15 but 2.6.16 and above should > work. Unfortunately, yes. One of the embedded platforms I develop for is based around 2.6.10. >> <snip> >> >>> What's your opinion ? Is someone strongly opposed to the switch ? If so >>> please state your reasons. All constructive opinions are welcome. >> I guess I would be opposed for teh reson above, but I'm probably a very >> small minority! > > Your opinion in nonetheless important. > > Maintaining backward compatibility in the uvcvideo driver itself wasn't that > much of a burden until now, but changes in the v4l core queued for 2.6.28 > would introduced a whole new set of #ifdef's all around the driver. The code > would become messy and I'd like to avoid that if possible. Hence the idea of > switching to Mercurial. I can see that you would wish to avoid that. Cheers Darren _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
