> >especially for new stuff. Maybe we should have some class/video (or v4l > >to avoid name clashes with the framebuffer video folks?) where all > >video4linux drivers are listed? And drop /proc/video in favor of this? > > > > Gerd > > Greg originally suggested using driverfs, and mentioned that eventually all > the V4L proc stuff will move over there. My only problem with using > driverfs now is that currently everything V4L is nestled in /proc/video, so > everybody knows where to go looking. If I'm off by myself and every one > else is in /proc/video I don't see that as a good thing. I suspect some code in videodev.c would be needed too for driverfs support, maybe I find some time to look into that once I'm done with the current, urgent v4l2 stuff. Patches also welcome of course. If you want to use procfs I'd suggest the one-file-per-value approach. You don't have to parse stuff inside the kernel then. I think there are even ready-to-use functions to handle int values in procfs files. And driverfs uses the same approach -- one file per option. Thus this scheme will stay the same if we switch over to driverfs some day. Gerd -- You can't please everybody. And usually if you _try_ to please everybody, the end result is one big mess. -- Linus Torvalds, 2002-04-20
