Duncan Haldane <f.duncan.m.haldane@xxxxxxxxxxxxxxxx> writes: > I found a discussion about "sysfs-ifying" drivers on this list, > but dont quite understand the details. > > Could I get some guidance? bytesex.org/patches has patches for 2.6.0-test3 which has updates for bttv. You might want to have a look at this. > -- The cpia.c driver creates,uses, and eventually destroys a > /proc/cpia/video<n> > for controlling /dev/video<n>. This is done by its own private > functions. (see cpia.c code in #ifdef CONFIG_PROC_FS ... #endif sections) > > Am I correct in assuming that its OK to leave this use of /proc > untouched, or is is "trivial" to convert it to sysfs ? Should be easy to convert this to sysfs. /sys/class/video4linux is the directory where all v4l-devices are listed, with subdirectories named "video0", "video1", "vbi0", ... videodev creates a "dev" file (with major/minor) and a "name" file (with vfd->name). If vfd->dev is set correctly by the driver there will also be "driver" and "device" symlinks. It is possible to create more files with attributes in that directory, bttv for example creates a (read-only) "card" file where the card number (i.e. card=<n> insmod option) is in. > -- what is the missing .release in struct video_device supposed to do? video_release() is called when the last reference to the sysfs class is gone and struct video_device can safely be freed. That may happen _after_ video_unregister() returns if one of the sysfs class files is busy for some reason. For most drivers it should be enougth to kmalloc() the struct video_device instead of embedding it into the drivers private data and let ->release point to the video_device_release() helper function to free it. Gerd -- sigfault
