On Tue, 2017-01-10 at 19:55 +0100, Lars Knudsen wrote
> And we're quite happy to keep blacklisting specific VID/PID > combos we > know are not modems. Another possible solution is to greylist > devices > that happen to have webusb descriptors, such that they won't > get auto- > probed, but could be probed on-demand via D-Bus. But I'd > rather that > happen via udev rules than MM trying to walk USB device > attributes and > parsing webusb descriptors. > > If greylisting prevents auto-probing, I think it would be very > valuable for devices with a WebUSB header because those will in most > cases (as I see them used) be industrial things (like my current > medical company employer) or IoT devices. And waiting ~16 seconds for > a fallback to USB Serial where WebUSB is not available (or for other > reasons not chosen), can be a real pain. > > > I agree that a solid udev rule would be a good way forward (I'll look > into greylisting and see if I can come up with something that covers) > and maybe this could also be the place to do the user space access (or > not - I'll try to come back with something. I am afraid this would not work. Or rather it would work once. But as soon as the driver is already loaded, it will bind and we have a beautiful race condition, which the kernel will almost certainly win. > And if we happen to look at a storage device we may see an unclean removal if you kick the kernel off a device. I am afraid if you really want to go to triggered probing, you need a sysctl for that. Regards Oliver _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel