Hey! On Sun, May 27, 2018 at 6:16 PM, Bjørn Mork <bj...@mork.no> wrote: > Never heard of "bind" events before. Googling them led me straight to > https://github.com/systemd/systemd/issues/8221 > which tells me that that I haven't been paying much attention for the > last 5 kernel releases... > > Except for that, this looks like a systemd bug. The Debian bug is > reported agains v237, so your v236 will be affected. >
Ohh, this explains everything I'm seeing indeed. > I will test your patch, but adding "bind" to every existing rule for > every device and every application cannot be right? This should be > handled by systemd-udev. > Yes, should be handled by systemd-udev, definitely. This is extremely unfortunate... But in the meantime, all the logic we have in place to handle udev tags at device level are affected. The udev tags we set for e.g. tagging port types aren't affected (as there's no bind event for the tty device), but all the udev tags for the blacklist and greylist are affected currently. So I believe there's something we need to do... maybe adding the tag on the bind event is overkill? There's another possibility that I see we could use, and that would be not to tag the device, but tag all the ports of the device instead. This is already supported in git master because the "udev-less" logic used in OpenWRT applies device-level tags in the different ports, so we could do the same to avoid this... The problem is that this would force us to keep this in place forever I guess... and that brings me back to thinking just adding the rules also in bind wouldn't be that bad. Note anyway, that this udev bug affects MM running in DEFAULT filter mode. If using the STRICT filter, as we're suggesting all distributions to use now, they would not be affected (as all port-level udev tags wouldn't be affected, and there's no blacklist/greylist filtering in STRICT mode). Well, a third option would be to hack our own port type rules, blacklist, greylist... without using udev at all. But I really wouldn't want to have to do that right now... Whenever we find a solution for this issue in our side, even if temporary, I'll suggest we release 1.8. -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
