[pvrusb2] pvrusb2 driver going into v4l...

[Mike Isely]

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


-- 
                         |         Mike Isely          |     PGP fingerprint
      Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                         |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                         |                             |