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 <[email protected] >>>> <mailto:[email protected]>> 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 >>>> <[email protected] >>>> <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> >>> 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
