1 |
On Sat, 9 Nov 2013 19:53:02 -0600 |
2 |
Barry Schwartz <chemoelectric@×××××××××××××.org> wrote: |
3 |
|
4 |
> |
5 |
> I figured as much. Please let us know if you come up with a good |
6 |
> technique that can be adapted to a MAKEDEV script or such. It is nice |
7 |
> to know how to dump e?udev, just in case; and I also use a scanner. |
8 |
> |
9 |
|
10 |
As soon as I plugged in the scanner (after starting the udev daemon) |
11 |
an entry was created in /run/udev/data for c189:131. This obviously |
12 |
refers to a device node for a character (c) file with a major number |
13 |
of 189 and a minor number of 131. This is all that is needed to access |
14 |
the device through the kernel. |
15 |
|
16 |
However, with udev and libusb there are user-space conventions. |
17 |
A utility such as libusb expects device nodes to be in a certain |
18 |
location, i.e. /dev/bus/usb, and to be named a certain name, i.e. |
19 |
001, 002, etc. If not for these conventions the device node could |
20 |
be placed anywhere and named anything. |
21 |
|
22 |
So, to stick to conventions, create the node in /dev/bus/usb: |
23 |
|
24 |
mknod --mode=0666 /dev/bus/usb/001 c 189 131 |
25 |
|
26 |
That's it. Now the scanner can be detected by libusb and SANE. |
27 |
Furthermore, this is a *permanent* device node. It will not |
28 |
disappear upon reboot. The udev daemon is needed only once |
29 |
to get the major/minor numbers. |
30 |
|
31 |
However, if the device is unplugged and then plugged back in again |
32 |
the minor number usually jumps. So just create a sequence of |
33 |
nodes to allow for this: |
34 |
|
35 |
mknod --mode=0666 /dev/bus/usb/002 c 189 132 |
36 |
mknod --mode=0666 /dev/bus/usb/003 c 189 133 ... |
37 |
|
38 |
Upon reboot, the node will reset back to the first minor number. |
39 |
|
40 |
If you check devices.txt in the kernel source documentation, these |
41 |
particular major/minor numbers are not listed for any device. I don't |
42 |
know where they come from, but as long as they work I don't care. |
43 |
However, this would preclude using something like MAKEDEV to pre-build |
44 |
these nodes. Also, user-space programs expect certain node naming |
45 |
conventions and I don't know where such conventions are listed. |
46 |
|
47 |
A new issue is determining how udev gets its device info. The kernel |
48 |
sends out a notice when it detects a new device and the udev daemon |
49 |
gets the notice and then reads the new kernel device parameters |
50 |
from somewhere. But from where? If this were known then any script |
51 |
could read the same parameters. |
52 |
|
53 |
In short, if udev reads data from the kernel then a simple custom |
54 |
program or script could accomplish the same thing. |
55 |
|
56 |
Frank Peters |