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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
