Re: [RFC/PATCH] sysfs'ify video4linux

[Greg KH <greg@kroah.com>]

On Thu, Jul 17, 2003 at 02:01:21PM +0200, Gerd Knorr wrote:
> On Wed, Jul 16, 2003 at 02:08:00PM -0700, Greg KH wrote:
> > On Wed, Jul 16, 2003 at 10:20:18PM +0200, Gerd Knorr wrote:
> > > Yes, it is allocated/freed by the driver, most seem to simply include
> > > one ore more "struct video_device" somewhere in the per-device struct.
> > 
> > So you CAN NOT just blindly put a kobject (meaning a class_device)
> > structure inside of there.
> 
> Why not ...
> 
> > > which want add private properties and rely on video_device->priv
> > > for finding the per-device data.  Problem isn't solved but justed
> > > moved to the next corner ...
> > 
> > No, just have the video drivers have a release callback to do the
> > freeing.
> 
> ... if a ->release() callback is required anyway to fix it?  I see two
> ways to handle it:
> 
>   (1) mandatory ->release() callback, drivers must make sure the stuff
>       is not freed before the callback was called.  In that case the
>       class_device can be left embedded inside the drivers provate
>       structs.

That sounds fine, and is the same as what I did for usb host devices.

>   (2) optional ->release() callback (for those drivers which want add
>       private attributes), "struct video_device" must be moved out of
>       the drivers private structs then and released in a new function
>       (which also calls the drivers ->release callback if present).
>       Should probably also be allocated by videodev.c for symmetry.

That's "prettier", but probably requires a lot more work in every v4l
driver, right?

> Both approaches require touching all v4l drivers in non-trivial ways
> through, not sure whenever it is a good idea to do that now.  Any chance
> to get that in before 2.6.0?  Or should I better make that change in
> 2.7.x and live with /proc for the time being?

I'd say you should try for it now.  It's required if you want support
for things like udev in 2.6, which is what a lot of people seem to
want...

I know there are still a few other subsystems that need this kind of
change in 2.6, so you are not alone (input, misc, parallel port, sound,
etc.)

I'd be glad to help you out with this if you want.

thanks,

greg k-h