[pvrusb2] pvrusb2 driver going into v4l...

[Bill Crowell]

Mike,

For many reasons, I think that you should go forward with inclusion in 
the main kernel.

Video has been the last big part of device support for Linux. With the 
V4L group and IVTV playing together, we can finally standardize this 
portion of the drivers. I see this as an opportunity for cleanup and 
moving the application layer products (KDEtv, XAWtv, etc.) forward.

I don't believe that maintaining backwards compatibility is as much a 
priority as getting the driver projects coordinated. Therefore, I would 
leave the current snapshots for those who require backwards 
compatibility and move updated code into the new kernel.

Having banged my head into the keyboard working with video, this portion 
of the system cleanup is quite welcome.


Regards to all,

Bill

Mike Isely wrote:

>
> I might have mentioned here a while back that I have been invited to 
> submit the pvrusb2 driver for inclusion into the v4l core and then 
> subsequent inclusion into the main kernel. This has been an open 
> invitation for a while and last weekend I (finally) started real work 
> to accomplish this goal. The ivtv driver by the way is also going into 
> V4L.
>
> During that effort to massage the sources into a V4L-acceptable form, 
> I uncovered a number of complicating issues. I won't bore you with the 
> details here. But it does lead to a key question that I'd like to get 
> some feedback on:
>
> The effort to ready the driver would be significantly easier if I 
> discarded any pretense towards supporting earlier versions of the 
> kernel and any version of ivtv. What do you all think about that? I 
> know it sounds radical, so let me fill in some details here...
>
> The ivtv driver is also being pulled into V4L, and I'm led to believe 
> that this effort is going quite well. A lot of the various 
> "problem-child" modules that pvrusb2 leverages from ivtv will finally 
> only exist in one version, that being V4L. This means that *going 
> forward*, there will no longer (in theory) be any traps / pitfalls 
> towards getting the pvrusb2 driver to play nicely with ivtv. However, 
> *going backwards*, this would also means that newer versions of the 
> driver (either in v4l or separately released) would NOT be able to 
> work with older versions of ivtv. I've tried to maintain complete 
> forwards / backwards compatibility with ivtv, but trying to do that 
> while simultaneously arranging things for a seamless fit directly into 
> V4L really really complicates things. Just to make the point really 
> clear: I want to forgo maintaining compatibility with older ivtv 
> releases. Breaking with backwards compatibility with ivtv would NOT 
> means that we can't work with ivtv anymore; it would mean that we 
> would no longer have any chance of working with *older* versions of 
> ivtv. With ivtv being pulled into V4L as well, it should actually be 
> easier to coexist with ivtv. Any thoughts on this anyone?
>
> As for earlier kernel versions, the pvrusb2 driver right now should 
> work with all kernel versions from roughly 2.6.10 (w/ relevant V4L 
> patches) up to the current kernel. However there are things I do in 
> the driver to maintain that backwards compatibility. But putting that 
> sort of stuff into a driver destined for ultimate inclusion in, say 
> the official 2.6.15 kernel tree, would seem kind of silly. I expect 
> right now that even after the driver goes into the kernel that I may 
> want to still maintain an out-of-tree snapshot for rapid development 
> of new code, and obviously I'd want that snapshot to stay as close as 
> possible to the in-tree version in the kernel. That would mean 
> discarding anything needed for the older kernel versions. Thoughts, 
> comments?
>
> There is a chance this driver might get into 2.6.15, though right now 
> I think the odds are low (it's almost too late for inclusion and I'm 
> really short on time for the next few days). However even if not 
> 2.6.15 then certainly 2.6.16 may be possible. I've never planned on 
> permanently hosting this driver, and this seems like a chance to give 
> the driver a place where it can live beyond any one person's attention 
> span. So I think it important to do the effort now to get it included, 
> but the effort will be a lot easier if I can drop backwards 
> compatibility with older kernels and older versions of ivtv. So what 
> do you all think?
>
> BTW, before anyone gets worried, no I am *NOT* looking to orphan this 
> driver. It's been a lot of fun working on this and I've actually quite 
> enjoyed helping people out. I plan to continue supporting and 
> expanding the driver, even after inclusion. For the first time, I'm 
> really able to give back to the Open Source community. In fact, I kind 
> of hope I can find other interesting stuff I can contribute in the 
> future (in V4L or whatever else looks interesting). But certainly I 
> don't expect to be hosting this driver forever. The obvious endgame is 
> kernel inclusion; the opportunity exists now, so let's do this...
>
> What do you all think?
>
> -Mike
>
>

-- 
William G. Crowell, VP & CTO
Crowell Systems
4235 South Stream Blvd Suite 100
Charlotte  NC 28217
704.665.2000 fax 704.665.2180