On Monday 05 February 2007 12:04, Axel Thimm wrote:
> On Mon, Feb 05, 2007 at 11:30:17AM +0100, Hans Verkuil wrote:
> > > I'm building packages for RHEL and FC as appropriate, they will
> > > land in atrpms-testing.
> >
> > Be aware of the new encoder firmware included with the package!
>
> I was always packaging v4l-cx2341x-init.mpg, or is there something
> else now?
>From the README:
NOTE: this driver requires the latest encoder firmware (version
2.06.039, size 376836 bytes). This firmware is temporarily included
with this driver. When this driver is released officially, then the
firmware archive on www.ivtvdriver.org will also be updated. But for
the time being you will have to copy the included firmware over your
current v4l-cx2341x-enc.fw firmware.
>
> > > > My intention is to release a ivtv-0.18.0 for kernel 2.6.18,
> > > > 0.19.0 for kernel 2.6.19 and a 0.20.0 for kernel 2.6.20. This
> > > > keeps the numbering nicely regular. There will probably also be
> > > > a 0.21.0 for kernel 2.6.21,
> > >
> > > If it wouldn't be a too big issue I would recommend using the
> > > same versioning throughout all supported kernels. I think it
> > > makes the users' handling easier, as well as for people reviewing
> > > the code, e.g. it is easier to review some conditionals based on
> > > kernel versions than to have several trees.
> > >
> > > It also makes packaging far more easier, as the userland portions
> > > remain in the same versioned subpackage, even if people have both
> > > 2.6.18 and 2.6.19 kernels and ivtv kernel subpackages installed.
> >
> > True, but on the other hand it is much more like what it will be
> > when the driver enters the kernel: only limited fixes for older
> > kernels. But I'm not yet certain how to handle this.
>
> Once the driver is in the kernel I wouldn't backport small fixes at
> all, I would simply move along with development of a single version
> while allowing the software to build for a certain kernel range,
> e.g. if certain APIs from 2.6.18 are needed then 2.6.18 upwards. If a
> small number of conditionals allow for a broader range of kernel
> that's OK (e.g. as long as the pain is small compared to the gain).
>
> That's the typical model followed by many projects, whether they are
> in the kernel already with some version or not, e.g. alsa, ipw*, v4l
> etc. It makes talking about features entering the driver easier,
> e.g. instead of "super-foo was added to 0.24.5, 0.25.2 and 0.26rc1"
> one would just have a single version.
>
> Having the version stick to the software itself and not correlate
> with the kernel version has also other benefits: Once it hits say
> 2.6.22 as an internal kernel module it would carry a modversion of
> 0.22.0. Perhaps 2.6.23 will see no changes at all, but the users will
> be confused about still being on 0.22.0 because they have been
> educated to associate the version of the module with that of the
> kernel's and also have been warned not to mix.
>
> And users could check whether their in-kernel or OOT version supports
> "super-foo" by the same kernel-independent method, a simple modinfo
> ivtv | grep ^version:
Once it is in the kernel there is no problem anymore: if you need the
latest functionality but have an older kernel, then you can 'just'
compile and install the latest v4l-dvb source tree. But I can't really
support an out-of-tree standalone ivtv package because ivtv relies
heavily on the v4l2 API changes that I'm making. That's why the trunk
ivtv can't be backported to pre-2.6.18 kernels (2.6.18 added the MPEG
encoder controls). Another cut-off point might be when the driver goes
into the kernel as that too requires new v4l2 API additions.
This is the reason why I basically stopped supporting ivtv-0.6 and 0.7
and only do very limited support for ivtv-0.4. (ivtv-0.5 was skipped)
Regards,
Hans
PS: of course it is technically possible to backport the trunk to older
kernels, but the amount of time it will take is just too much.
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
