[cpia] USB anyone?

[Jochen Scharrlach]

sbertin@mindspring.com writes:
 > That call is redundant (maybe) and will only occur if the the camera is
 > open when cpia_unregister_camera is called. cam->ops will only be NULL
 > if the camera was removed.  See the FIXME comment in
 > cpia_unregister_camera.  This either needs to be made conditional on
 > cam->open_count == 0 or removed from cpia_close.  Until this can be
 > tested with a USB camera I can't tell which is correct.  Having it
 > called twice is clearly wrong though.

Have you asked the i4l-crowd about this? I don't think that a close()
on an unregistered video_device would be *possible*! The code looks
like this:

static int video_release(struct inode *inode, struct file *file)
{
        struct video_device *vfl=video_device[MINOR(inode->i_rdev)];
        if(vfl->close)
                vfl->close(vfl);
        vfl->busy=0;
        return 0;
}

void video_unregister_device(struct video_device *vfd)
{
        if(video_device[vfd->minor]!=vfd)
                panic("vfd: bad unregister");
        video_device[vfd->minor]=NULL;
        MOD_DEC_USE_COUNT;
}

As soon as you unregister a device it is not possible to jump into the
close()-command (via video_release()) of the v4l-driver, because the
entry in video_device[] is set to NULL! If it makes trouble, it'll
make *real* trouble (testing vfl->close if vfl is NULL? ouch!) when you
disconnect an open camera and I don't think you're code will be able
to save the day...

 > That's correct, but imcomplete.  The problem case is where the camera is
 > removed when it is open.  The low level driver should get rid of its
 > information about the camera, but the higher level still needs some
 > information until close is called.  I don't want to discourge you, but
 > keep this case in mind as you design something to replace the existing
 > system.

As I said, the 2.3.37 i4l-code makes it impossible to call the
close()-function of an unregistered i4l-device and I don't see any
reason why they should change this :)

Bye,
Jochen

-- 
new signature coming RSN (tm)