[systemd-devel] Use a specific device ?

[poma]

On 05.06.2015 16:13, Jean-Christian de Rivaz wrote:
> Le 05. 06. 15 15:41, poma a écrit :
>> 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 :)
>>
> 
> This is only a symbolic link and ModemManager don't use symbolic link. 
> In addition this will not work for modems with multiples serial ports 
> where ModemManager select a unpredictable ports because of device or bus 
> or kernel or udev timing that affect the order when the ports are added 
> (I don't known the exact cause but I have a system where this exists).
> 
> Jean-Christian
> 


I think Dan explained several times why this is happening in the first place.

I am somewhat pleased because MM does not probe my GPU.