[cpia] CPiA driver news: cpia-control-0.4 released

[Nick Holloway]

f.duncan.m.haldane@worldnet.att.net (Duncan Haldane) writes:
> I also found some time last weekend to get patches for the
> Kernel maintainers ready and tested, so the work in the sourceforge
> CVS source won't just get lost.

I'm really glad that this stuff is getting pushed to the mainstream kernel
-- as you say, it prevents the CVS source from mouldering in a corner.

Is anyone looking at getting cpia updated for 2.5.x?

I had a go at getting cpia to compile under 2.5 with the various API
changes.  I reckon that I've battled about 80% of the way, basing my
changes on the way that other drivers have been updated.  I'd like to
try and complete this, maybe waiting to see if v4l2 does land before
Halloween.

My main feeling from the work so far, is that the extent of the changes
mean that it is not feasible to augment the current source with more of
'#if (LINUX_VERSION_CODE...'.  For example, my current code has this
for cpia_mmap:

    #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0))
    static int cpia_mmap(struct file *file, struct vm_area_struct* vma )
    {
	    unsigned long start = vma->vm_start;
	    unsigned long size  = vma->vm_end - vma->vm_start;
	    struct video_device *dev = video_devdata(file);
    #else
    static int cpia_mmap(struct video_device *dev, const char *adr,
			 unsigned long size)
    {
	    unsigned long start = (unsigned long)adr;
    #endif

The area around the memory handling is worse, and I think this is just
too difficult to maintain.

What do people[1] think of the idea of producing a set of cpia*.[ch] for
the 2.5 kernel, free from the baggage of earlier kernel support?

-
[1] If there is anybody out there :-)

-- 
 `O O'  | Nick.Holloway@pyrites.org.uk
// ^ \\ | http://www.pyrites.org.uk/