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 <[email protected]> To: Communications nexus for pvrusb2 driver <[email protected]> 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 [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
