On Tue, 27.01.15 08:41, Martin Polednik (mpoled...@redhat.com) wrote: > > b) Expose this via udev .link files. This would be appropriate if > > adding/removing VFs is a one-time thing, when a device pops > > up. This would be networking specific, not cover anything else like > > GPU or storage or so. Would still be quite nice. Would probably the > > best option, after a), if VFs cannot be added/removed dynamically > > all the time without affecting the other VFs. > > > > c) Expose this via udev rules files. This would be generic, would work > > for networking as well as GPUs or storage. This would entail > > writing our rules files when you want to configure the number of > > VFs. Care needs to be taken to use the right way to identify > > devices as they come and go, so that you can apply configuration to > > them in a stable way. This is somewhat uglier, as we don't really > > think that udev rules should be used that much for configuration, > > especially not for configuration written out by programs, rather > > than manually. However, logind already does this, to assign seat > > identifiers to udev devices to enable multi-seat support. > > > > A combination of b) for networking and c) for the rest might be an > > option too. > > I myself would vote for b) + c) since we want to cover most of the > possible use cases for SR-IOV and MR-IOV, which hopefully shares > the interface; adding Dan back to CC as he is the one to speak for network.
I have added b) to our TODO list for networkd/udev .link files. c) should probably be done outside of systemd/udev. Just write a tool (or even documenting this might suffice), that creates udev rules in /etc/udev/rules.d, matches against ID_PATH and then sets the right attribute. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel