[pvrusb2] pvrusb2 with 2.6.35-rc4

[devsk]

Mike,

Thanks so much for the detailed response. It makes things clear and assures me 
you are in complete control here. 


There is no real hurry, take your time. I am currently running 2.6.34. So, I am 
good.

Thanks,
-devsk




________________________________
From: Mike Isely <isely at isely.net>
To: Communications nexus for pvrusb2 driver <pvrusb2 at isely.net>
Sent: Wed, July 7, 2010 9:21:28 PM
Subject: Re: [pvrusb2] pvrusb2 with 2.6.35-rc4

On Mon, 5 Jul 2010, devsk wrote:

> Mike,
> 
> I was trying to build 2.6.35-rc4 for other reasons but ran into this compile 
> error while building my usual out-of-kernel modules:
> 
> Any ideas? Any quick patches?
> 
>   CC [M]  /usr/src/pvrusb2-mci-20100425/driver/pvrusb2-v4l2.o
> /usr/src/pvrusb2-mci-20100425/driver/pvrusb2-v4l2.c: In function 
>'pvr2_v4l2_do_ioctl':
> /usr/src/pvrusb2-mci-20100425/driver/pvrusb2-v4l2.c:320: error: incompatible 
>type for argument 2 of 'v4l2_prio_check'
> include/media/v4l2-common.h:94: note: expected 'enum v4l2_priority' but 
>argument is of type 'enum v4l2_priority *'
> /usr/src/pvrusb2-mci-20100425/driver/pvrusb2-v4l2.c: In function 
>'pvr2_v4l2_release':
> /usr/src/pvrusb2-mci-20100425/driver/pvrusb2-v4l2.c:1217: error: incompatible 
>type for argument 2 of 'v4l2_prio_close'
> include/media/v4l2-common.h:92: note: expected 'enum v4l2_priority' but 
>argument is of type 'enum v4l2_priority *'
> make[2]: *** [/usr/src/pvrusb2-mci-20100425/driver/pvrusb2-v4l2.o] Error 1
> make[1]: *** [_module_/usr/src/pvrusb2-mci-20100425/driver] Error 2
> 
> BTW: How old (or new) is the in-kernel module? That builds fine with the 
>kernel. 
>
> How can that be? Are there patches in the in-kernel version which are not in 
> 0425 version?
> 

I have more information on this.

First, to answer your question about the in-kernel version of the 
driver (and this lays the foundation to explain the problem):

There are actually 3 parallel-tracked "editions" of the driver at any 
given moment: (1) the in-kernel version, (2) the in-V4L version, and (3) 
the standalone version.  They are all mechanically related.  The 
standalone driver version has the most code - this is because it is 
compilable against the widest range of kernels - all the way back to 
2.6.12.  The in-V4L version is smaller because it only needs to compile 
against a narrower kernel range, that is, the range of kernel versions 
supported by the Mercurial v4l-dvb snapshot.  The in-kernel driver is 
the smallest of the three because it is specifically targeted to the 
exact kernel in which it lives.  Nearly all of the development I do on 
the driver happens in the standalone driver because that gives me the 
widest range of testing capabilities (again because it has more features 
targetable to more kernels).  Every once in a while I do some direct 
work on the in-V4L version, if I am dealing with a problem that is best 
chased within a v4l-dvb snapshot.

I use a Perl program designed to systematically transform the standalone 
driver into the in-V4L version.  This works by evaluating various 
#define options appropriate for v4l-dvb - you can see the whole list in 
pvrusb2-options.h (a file which is only in the standalone driver).  
Thus keeping the in-v4l version in sync with the standalone driver is 
just a matter of running a script.  I usually do this at about the same 
time I roll out a new snapshot.  Similarly, the v4l-dvb maintainer runs 
a transformation to further strip the driver (and all other parts of 
v4l-dvb) into a form appropriate for insertion directly into a specific 
kernel.  That's how the in-kernel pvrusb2 driver is tracked.  (More on 
that further down.)

Most changes in the driver flow in this manner: standalone -> in-V4L -> 
in-kernel.  Of course there are other changes that originate in the 
other two driver versions.  Fixes from other kernel maintainers start 
with the in-kernel driver, but the v4l-dvb maintainer ports those 
changes back to the v4l-dvb Mercurial repository.  From there I usually 
just generate an hg changeset and directly apply that against the 
standalone driver, which most of the time applies cleanly (and if it 
doesn't it is usually obvious why).  I tend to do this "reverse" flow 
periodically and/or when I learn of incoming pvrusb2 driver patches.  
If an incoming change like this is important enough, I will usually also 
release another standalone snapshot that incorporates it as well.

That's how the 3 drivers "editions" stay in sync.  I've done it this way 
now for about 5 years.

A related item: Recently v4l-dvb development has been moving from 
Mercurial over to git.  This is a nice change in the end, but it's more 
than just a change of SCM because it also changes the v4l-dvb workflow. 
Effectively now everyone is working with the exact in-kernel version(s) 
of v4l-dvb (using git's efficient branching to move patches around as 
needed) not the Mercurial version.  This is something that my own 
workflow has not caught up with yet.  The v4l-dvb developers are still 
maintaining the Mercurial repository but I get the impression that since 
it's not really the "main line" anymore then as time goes forward I 
really need to get going better with git.  This is why a number of 
recent pvrusb2 changes have taken an unusually long time to flow back 
into the kernel :-(

Back to the main problem here...  I track the standalone driver sources 
using a Subversion repository.  When I release a new version of that 
driver, I run a script that tags the sources from the trunk, creates a 
version-specific header, and then generates the tarball that is then put 
up on the web site.  So I grabbed the latest tarball (20100425 as devsk 
pointed out) and sure enough it won't compile in 2.6.35-rc4.  Then I 
compiled my Subversion trunk against 2.6.35-rc4 - and THERE it compiles 
clean.  So there are changes sitting in Subversion that fix this that 
apparently I was unaware of and that's why it hasn't appeared in a new 
snapshot.  Clearly I need to just release a new snapshot.  I will do 
that, but first I need to isolate the change that is fixing this and 
ensure that I understand why, in case there are other things lurking 
here.

So stay tuned, there will soon be a new snapshot released of the 
standalone driver.

BTW, if you're really impatient, here's a little secret.  Ensure you 
have Subversion installed and try this:

    svn checkout http://www.isely.net/svn/pvrusb2/trunk pvrusb2

That will give you direct access to the Subversion repository from where 
the snapshots are spawned.  If you do a checkout like this, you will get 
a directory layout that is identical to the standalone snapshots and the 
compilation procedure is the same as that for the standalone driver.  
EXCEPT you will also need to generate a file called "pvrusb2-version.h".  
That is a simple header which labels the version of the driver; it is 
normally generated by the snapshot generating script.  Easiest way to 
understand the header is to copy one from a snapshot and edit its 
contents so you can avoid confusion later.

I guess now this isn't such a secret anymore :-)  No guarantees; the 
access might disappear tomorrow if it becomes a problem and of course 
the driver might not be as stable as a released snapshot.  YMMV.

I will get a new snapshot out as soon as I can (likely one more day so I 
can verify a few other things).

  -Mike



-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
_______________________________________________
pvrusb2 mailing list
pvrusb2 at isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2