Because of the high volume at this list, it is essential that
- you keep everyone who posted in a tread in the Cc: list of your
replies, (that way it is possible to discuss on LKML even with
people who are not subscribed; but more importantly, people who
take part in a discussion are less likely to miss replies),
- you actually reply rather than start new threads all the time.
So, as Randy already asked you, please use reply-to-all when continuing
this discussion. That way (and with other measures like good subjects,
or respectively keeping the subject in replies if applicable) the list
volume becomes easily manageable.
Aren't those drivers ones for
- input devices,
- display devices (in a more general sense than visual displays, i.e.
also including audible and tactile displays)?
Besides, if you had for example an USB device of that type, the most
natural place for its sources would be somewhere beneath drivers/usb/.
About the userspace interfaces of such drivers:
- As was noted, /proc is generally not for userspace ABIs except to
expose properties of processes and a few selected other core properties
of the kernel.
- /sys is for userspace ABIs which specifically pertain to properties
of kernel objects, notably properties of the kernel representations of
devices and of kernel modules. Have a look into /sys/devices, /sys/bus,
and /sys/modules to get an idea. Note, a lot of what is exposed in /sys
does not constitute stable long-time supported ABIs; see
Documentation/sysfs-rules.txt.
- There are other types of ABIs for I/O (character device files, block
device files), message-based(?) I/O (netlink), configuration (configfs),
and more.
I have no idea what kind of communication with userspace the various
accessibility related drivers maintain.
--
Stefan Richter
-=====-==--- --=- =-=--
http://arcgraph.de/sr/
--
