[Linux-uvc-devel] [RFC] Switching from SVN on Berlios to Mercurial on linux-tv.org

[Darren Longhorn]

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