[systemd-devel] Use a specific device ?

poma pomidorabelisima at gmail.com
Fri Jun 5 06:41:18 PDT 2015


On 05.06.2015 15:29, Harald Hoyer wrote:
> On 05.06.2015 15:28, Mantas Mikulėnas wrote:
>> On Fri, Jun 5, 2015 at 4:22 PM, Harald Hoyer <harald.hoyer at gmail.com
>> <mailto:harald.hoyer at gmail.com>> wrote:
>>
>>     On 05.06.2015 15:09, poma wrote:
>>     > On 05.06.2015 14:14, Jean-Christian de Rivaz wrote:
>>     >> Le 05. 06. 15 13:18, Aleksander Morgado a écrit :
>>     >>> On Tue, May 26, 2015 at 12:19 AM, Jean-Christian de Rivaz <jc at eclis.ch
>>     <mailto:jc at eclis.ch>> wrote:
>>     >>>> I have a system where the modem have multiple /dev/ttyACMx ports where
>>     x is
>>     >>>> not constant because of the dynamic nature of others serial devices.
>>     >>> It may be worth noting that a very similar issue with the one faced
>>     >>> here is the one with network interface names, where interface names
>>     >>> were created as kernel drivers probed the different interfaces, ending
>>     >>> up with "eth0", "eth1" and so on. Then, there would be network
>>     >>> interface configurations for each network interface based on the name,
>>     >>> but no one really ensured that the name was the same upon reboots. The
>>     >>> solution provided by systemd to ensure that the proper configuration
>>     >>> is applied always to the proper interface is to make the device names
>>     >>> "predictable", see:
>>     >>>
>>     http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
>>     >>>
>>     >>> This solution avoids the need of any other udev rules to e.g. create
>>     >>> network interface names containing the device MAC address or what not.
>>     >>>
>>     >>> I'm wondering whether the same could be applied not only to network
>>     >>> interfaces, but also to ttyACMs, ttyUSBs and cdc-wdms, and end up
>>     >>> having predictable tty names like e.g. /dev/ttyACMp0s20u4i0. Sure,
>>     >>> those names are a nightmare to type, but they are predictable (e.g. in
>>     >>> this case by including the physical location of the connector of the
>>     >>> hardware).
>>     >>>
>>     >>
>>     >> This would be a wonderful solution. The only problem is when will this
>>     >> feature be available in a stable Linux kernel widely used by all majors
>>     >> distributions? Until this dream happens (probably not before severals
>>     >> years I guess), an other option must be implemented.
>>     >>
>>     >> Jean-Christian
>>     >
>>     >
>>     > Face your broadband modem, live your dreams?
>>     >
>>     > Kay, when this would happen - Predictable Broadband Modem Interface Names?
>>     >
>>
>>     Wouldn't it be nicer to have symlinks like in /dev/disk ?
>>     /dev/tty/by-path/....
>>
>>
>> 60-serial.rules:16:ENV{ID_PATH}=="?*", ENV{.ID_PORT}=="",
>> SYMLINK+="serial/by-path/$env{ID_PATH}"
>> 60-serial.rules:17:ENV{ID_PATH}=="?*", ENV{.ID_PORT}=="?*",
>> SYMLINK+="serial/by-path/$env{ID_PATH}-port$env{.ID_PORT}" 
>>
>> -- 
>> Mantas Mikulėnas <grawity at gmail.com <mailto:grawity at gmail.com>>
> 
> There we go.. already implemented :)


But not dracut-mented:
# lsinitrd initramfs-4.1.0-0.rc5.git0.1.fc23.x86_64.img | grep 60-serial.rules ; echo $?
1


https://github.com/systemd/systemd/blob/master/rules/60-serial.rules




More information about the systemd-devel mailing list