Unambiguous tty for USB devices in FreeBSD
A few years ago, we had to solve the following problem. A host running FreeBSD connects several USB devices of the same type. Host software works with them through character device files. It is clear that if you randomly switch the USB lanyards or when the host reboots, the files of character devices are numbered (in the general case) in a completely different order than when they were first connected. In my case, USB devices are interface converters on which RS-485 buses with devices hang. There is no way to automatically determine from the devices in the bus which buses are hanging on which port. Thus, it is not clear which symbol device files correspond to which physical devices at the moment. Who cares about the solution, please, under cat. Despite the specificity of the task, the method is universal.
Idea.When connecting a USB device, determine the file name of the character device that is issued by the system (such as ttyUx), the manufacturer, type, s / n of the device and create a link in / dev with a predefined name for this s / n, pointing to the already known ttyUx. T.O. our software will always work with well-known character device file names - predefined links that correspond to a specific device.
Implementation.
To find out more about a USB device:
Editing /etc/devd.conf. We write something like:
I think the meaning of this entry is clear. It remains to "draw" uplcom2ttyU, which will create the same link, unambiguous, in the example - / dev / icpcon1. For each device, you need to make an appropriate entry in devd.conf. Do not forget to change the name of the link (I have / dev / icpcon1) in two places: attach, detach, - we want the link to disappear when the device is turned off.
It can be seen that the uplcom entry changes to ttyU, since in / dev the system creates exactly ttyUx, where x matches the uplcom number.
That's all. However, until now a complete description of the solution to this problem cannot be found on the Internet. Unless only my posts on the forum of one well-known resource.
Idea.When connecting a USB device, determine the file name of the character device that is issued by the system (such as ttyUx), the manufacturer, type, s / n of the device and create a link in / dev with a predefined name for this s / n, pointing to the already known ttyUx. T.O. our software will always work with well-known character device file names - predefined links that correspond to a specific device.
Implementation.
To find out more about a USB device:
usbconfig dump_device_desc
...
ugen1.2: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0110
bDeviceClass = 0x0000
bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0000
bMaxPacketSize0 = 0x0040
idVendor = 0x067b
idProduct = 0x2303
bcdDevice = 0xa7d4
iManufacturer = 0x0001
iProduct = 0x0002
iSerialNumber = 0x0003 <0000A7D4>
bNumConfigurations = 0x0001
...
Editing /etc/devd.conf. We write something like:
# When the ICPCON USB Converter appear...
attach 100 {
match "device-name" "uplcom[0-9]";
match "vendor" "0x067b";
match "product" "0x2303";
match "release" "0xa7d4";
action "/usr/local/bin/uplcom2ttyU $device-name /dev/icpcon1";
};
detach 100 {
match "device-name" "ugen+";
match "vendor" "0x067b";
match "product" "0x2303";
match "release" "0xa7d4";
action "rm /dev/icpcon1";
};
I think the meaning of this entry is clear. It remains to "draw" uplcom2ttyU, which will create the same link, unambiguous, in the example - / dev / icpcon1. For each device, you need to make an appropriate entry in devd.conf. Do not forget to change the name of the link (I have / dev / icpcon1) in two places: attach, detach, - we want the link to disappear when the device is turned off.
cat /usr/local/bin/uplcom2ttyU
#!/bin/sh
# arg #1 - $device-name from devd.conf - uplcomX; arg #2 - new link to ttyUX - /dev/.....
ln -s $(echo /dev/$1 | sed 's/uplcom/ttyU/g') $2
It can be seen that the uplcom entry changes to ttyU, since in / dev the system creates exactly ttyUx, where x matches the uplcom number.
That's all. However, until now a complete description of the solution to this problem cannot be found on the Internet. Unless only my posts on the forum of one well-known resource.