While this may be a good idea in general, it could possible be done in userspace (the whole concept is basically linking USB ID's to capability sets, so there is no need for this to be in-kernel, right?).
Yes and no... we can have that stuff in userspace, of course, but I think that we are walking to a big salad here. Imagine this: some fingerprint devices have userspace drivers while others have kernel-mode drivers, while the majority of other USB devices (that could also be implemented in userspace) are in kernel-space. Why care to keep that stuff in userspace (except for security, since less non-critical code in userspace == stability+security), while we still have other devices being managed in kernel mode ? Another thing is that this "device information layer" should also be implemented not only for fingerprint devices, but for other USB devices too... and possibly (very likely) to other devices that are not USB. If such device-class-specific properties layer is to be implemented, we should do it to all device classes (not bind to any specific BUS type).
Also, in the less general case of fingerprint readers, most drivers will be in userspace. The upek one is, a driver being developed for the Authentec AES4000 is, and dpfp will be if the USB stack is now mature enough to allow libusb to bind to the fingerprint reader while the kernel usbhid driver is bound to the keyboard interface on the same device. So, defining some kind of structure for /sys/class/fingerprint won't apply to many of the supported devices.
I think that the kernel should be aware of the properties of the devices that it handles, otherwise we're walking to some kind of microkernel architecture, where one day we'll have everything running on userspace... Well, I'm not aware if there's any sensus regarding moving device drivers to userspace, but this sounds to me more like a decision made by fingerprint devices manufactures (as there are lots of SDKs that comes with userspace drivers, instead of a kernel driver for their devices). In order to keep a uniform standard, we should keep this on kernel space. Things like match algorithm implementations, indeed, should be kept at userspace.
Yes - I agree that there needs to be some common abstraction for fingerprint readers. When we have more device support, we should look at providing a fingerprint processing library, which supports as many devices as possible through a common interface.
Do you have any idea about how many fingerprint readers have linux support (i.e., kernel mode drivers, instead of dozens of per-manufacturer SDKs) ? Thanks Daniel -- What this world needs is a good five-dollar plasma weapon. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
