Daniel Bonekeeper wrote:
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 ?
You kind of answered your own question before you asked it, but let me
try and clarify my view. Two things:
1. We generally try and implement things in userspace where possible and
where it makes sense at least to a certain degree. Or at least, you only
get USB stuff included in the kernel when you have convinced Greg it
belongs there (which you may have already done).
2. As you acknowledge, only a certain subset of all USB fingerprint
reader drivers will be implemented in the kernel, therefore providing
the abstraction at kernel level is inadequate (you leave the pure
userspace drivers out of the loop, therefore getting people to actually
use your interface will be difficult). You may argue that your proposal
doesn't limit itself to fingerprint readers, but neither does my answer:
many USB devices (of other types) are supported purely in userspace.
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).
Sounds like you are talking about reimplementing HAL at this point. I
don't think this argument justifies including it at kernel level (but
neither does it oppose it).
I think that the kernel should be aware of the properties of the
devices that it handles,
If the kernel doesn't *need* to know about the properties and doesn't
act on them, why? And what about the devices that the kernel doesn't
handle, where they are operated purely through userspace?
otherwise we're walking to some kind of
microkernel architecture, where one day we'll have everything running
on userspace...
That's not what I'm suggesting - many classes of drivers belong in
kernel space and would incur major brain damage if moved to userspace.
You might want to go back a year or two and read the discussions when
the USB scanner driver was moved out of the kernel and reimplemented
100% inside libsane. There are other examples as well.
but this sounds to me more like a
decision made by fingerprint devices manufactures
It's not their decision while they aren't the ones writing the drivers.
Do you have any idea about how many fingerprint readers have linux
support
idmouse is the only fingerprint reader driver in the Linux kernel that I
know of. There are a number of other devices supported in userspace.
Daniel
-
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]
