[pvrusb2] latest snapshot is failing to build with 2.6.37
Mike Isely
isely at isely.net
Fri Jan 7 18:08:54 CST 2011
I'm afraid it may be a while this time. I've just spent the past couple
of hours looking at this. The problem isn't the code; it's the process.
Let me explain...
There is a Perl program I wrote long long ago that is able to execute a
programmed transformation on the source code. Conceptually it's very
simple: The script has in it a set of preprocessor names with an
indication of whether it should be defined or not. This program walks
through each source and performs the effect of that transformation. So
if, say, there is a chunk in a source file like this:
<...>
a = 1;
#ifdef FOO
b = 2;
#endif
c = 3;
<...>
And if the perl program is told that FOO should be defined then it will
remove the #ifdef/#endif pair in the transformation process. Similarly
if the perl program is told that FOO should not be defined, then it will
still remove the #ifdef/#endif pair but it will also remove the "b = 2;"
piece in the middle. If the Perl program encounters #ifdef/#endif
sequences for things not recognized, then it leaves those definitions
alone. Effectively, the program does a partial C-preprocessor expansion
on the source code.
There's more to it than just that (some file renames, handling of
nesting, syntax variations, etc) but that's the concept.
So using this program I can take a standalone tarball and transform it
into the stripped-down source used by the v4l-dvb project - which
ultimately ends up in the kernel. To track all of this, I have a
Mercurial checkout nearby. To move changesets into Mercurial, then all
I have to do is repeat the transformation on my end once per Subversion
snapshot and then just use hg commit to generate the corresponding
Mercurial changeset. These then get put into a Mercurial repository,
which is made available to the the v4l-dvb maintainer, whereupon the
changes eventually find their way into the next kernel release.
For the reverse direction, i.e. changes from others flowing back to the
standalone driver, I just run the transformation anyway and use hg diff
to create a patch file of what the transformation just undid. Then I
can reverse-patch that into the Subversion side. I then verify that it
applied cleanly by running the transformation back to the Mercurial side
and noting no further changes...
I know it sounds fairly complex, but I've actually worked it out into a
smooth process and this is in fact how things have been tracked now for
quite a long time (5+ years). This is why the pvrusb2 driver even today
still compiles against kernels as old as 2.6.11!
Starting early last year, the v4l-dvb developers began a migration over
to Git. This is more than just a change of SCM; it's also a change of
development process. Previously in Mercurial (and conceptually similar
to what I've done all along in the pvrusb2 driver), the v4l-dvb source
tree was maintained as a sort of "superset" that could at any time be
compiled against a range of kernel releases. This worked because the
v4l-dvb code contained extra #ifdef's that resolved differently at
compilation time depending on the kernel version being compiled against.
When changes in v4l-dvb were propogated to the kernel, a process similar
to what I did for the pvrusb2 driver took place: a program was run to
transform the superset v4l-dvb code into something appropriate for the
kernel. But with the move to Git, all this went away, to more closely
track actual kernel development. In particular, there isn't really a
single development trunk anymore. I can't just check out a tree and
then build it against a kernel. Rather now, the kernel and the tree are
already welded together since the v4l-dvb changes now are just regular
old boring branches against the kernel. Every new kernel release now a
new v4l-dvb branch against that kernel's tag (and presumably then all
the previous changes in the old branch that weren't accepted yet into
the kernel are then just rebased into the new branch). This eliminates
the need to maintain a single "superset" of v4l-dvb but it also means
that I must target different branches when transforming the standalone
driver. This is not a showstopper, but I'm trying to illustrate why I'm
not going to have new standalone driver source ready yet...
One can argue the pros / cons of this development process, but in the
end it's really the right thing. During this transition and for some
time afterwards, the Mercurial tree was supposed to be maintained in
parallel, i.e. changes were still moved back/forth to support people
like me who have been too lazy to learn the new system. This seemed to
go on for a while, but well...
So I've been relying on Mercurial as my connection into the kernel.
But today I just did an hg pull to update my local snapshot against the
official tree and ONLY THREE changesets were pulled. Considering the
fact that I haven't done this in several months (early October 2010) and
that there's obviously a lot of v4l-dvb development going on, it appears
that Mercurial support in v4l-dvb has evaporated. This leaves me
disconnected, unable to resync.
In particular, the released changes in 2.6.37 which have caused the
standalone pvrusb2 driver to miscompile now are not in Mercurial either,
so there's nothing for me to sync up against and fix.
Obviously this means I have to finally get off my *ss and fix everything
to sync up against Git instead of Mercurial. It's my own fault for
sitting on this so long, but that doesn't matter now. I've spent the
past couple of hours looking at this, but it's looking like I have a
long ways yet to go. There are also local changes in the standalone
driver in Subversion which didn't make it into Mercurial and I have to
also shovel those out of the way before I can begin a serious effort to
sync up against Git.
Anyway, I'm working on it. Sorry about all this.
I'm also considering other options, like given the maturity of the
driver these days, ending the standalone snapshots from Subversion and
rebasing on Git anyway. The surrounding development process these days
is a lot different than when I started working on this driver in early
2005; perhaps I should just get with the times...
My life has been very very VERY swamped since at least roughly last
September.
-Mike
On Wed, 5 Jan 2011, JE Geiger wrote:
>
> I just tried the in-kernel pvrusb2 driver and it works on the analog side
> for cable NTSC RF signals.
>
> Let me know and I will compile and test the snapshot when it is ready.
>
>
>
> -----Original Message-----
> From: pvrusb2-bounces at isely.net [mailto:pvrusb2-bounces at isely.net] On Behalf
> Of Mike Isely
> Sent: Wednesday, January 05, 2011 8:15 AM
> To: Communications nexus for pvrusb2 driver
> Subject: Re: [pvrusb2] latest snapshot is failing to build with 2.6.37
>
>
> Given that the in-kernel driver is obviously building fine, then this is
> just a case of me needing to pull back the patches that deal with this
> change (and ifdef the changes so that the driver continues to build OK with
> older kernels).
>
> I will get this dealt with but the absolute earliest I will be able to take
> care of it will be Friday. My day-job has me completely saturated through
> Thursday night.
>
> -Mike
>
>
> On Wed, 5 Jan 2011, JE Geiger wrote:
>
> > Same results here. Using 2.6.37.
> >
> >
> >
> > Looks like they diddled the functions around
> >
> > v4l: subdev: Merge v4l2_i2c_new_subdev_cfg and v4l2_i2c_new_subdev
> >
> > in 2.6.37.
> >
> >
> >
> > Took me so long to compile that you probably already have the fix.
> >
> > Send to the list when new snapshot is ready and I will retry.
> >
> > Don't you just love API changes after all this time.....
> >
> > On Wed, Jan 5, 2011 at 7:53 AM, Mike Isely <isely at isely.net> wrote:
> > >
> > > Well he did say 2.6.37 in the subject line...
> > >
> > > I was just thinking about this.
> > >
> > > In any case right now I believe the in-kernel driver is currently up
> > > to date with respect to the snapshot, but I will work this out and
> > > get a new snapshot ready ASAP.
> > >
> > > -Mike
> > >
> > >
> > > On Wed, 5 Jan 2011, JE Geiger wrote:
> > >
> > >> What version of the kernel are you building against/with ???
> > >>
> > >> On Wed, Jan 5, 2011 at 5:26 AM, devsk <funtoos at yahoo.com> wrote:
> > >> > /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c: In function
> > >> > 'pvr2_hdw_load_subdev':
> > >> > /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2576:7:
> > >> > warning: passing argument 4 of 'v4l2_i2c_new_subdev' makes
> > >> > integer from pointer without a
> > >> > castinclude/media/v4l2-common.h:148:35: note: expected 'u8' but
> > >> > argument is of type 'const char *'
> > >> > /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2576:7:
> > >> > warning: passing argument 5 of 'v4l2_i2c_new_subdev' makes
> > >> > pointer from integer without a cast
> > >> > include/media/v4l2-common.h:148:35: note: expected 'const short
> unsigned int *'
> > >> > but argument is of type 'short unsigned int'
> > >> > /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2576:7: error:
> > >> > too many arguments to function 'v4l2_i2c_new_subdev'
> > >> > include/media/v4l2-common.h:148:35: note: declared here
> > >> > /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2596:7:
> > >> > warning: passing argument 4 of 'v4l2_i2c_new_subdev' makes
> > >> > integer from pointer without a cast
> > >> > include/media/v4l2-common.h:148:35: note: expected 'u8' but
> > >> > argument is of type 'const char *'
> > >> > /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2596:7: error:
> > >> > too many arguments to function 'v4l2_i2c_new_subdev'
> > >> > include/media/v4l2-common.h:148:35: note: declared here
> > >> > make[2]: *** [/usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.o]
> > >> > Error 1
> > >> > make[1]: *** [_module_/usr/src/pvrusb2-mci-20100708/driver] Error
> > >> > 2
> > >> > make[1]: Leaving directory `/var/tmp/linux'
> > >> > make: *** [modules] Error 2
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > pvrusb2 mailing list
> > >> > pvrusb2 at isely.net
> > >> > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
> > >> >
> > >> _______________________________________________
> > >> pvrusb2 mailing list
> > >> pvrusb2 at isely.net
> > >> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
> > >>
> > >
> > > --
> > >
> > > 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
> > >
> > _______________________________________________
> > pvrusb2 mailing list
> > pvrusb2 at isely.net
> > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
> >
>
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
More information about the pvrusb2
mailing list