On Mon, 20.02.17 15:34, Viktor Mihajlovski (mihajlov@xxxxxxxxxxxxxxxxxx) wrote: > But then, I find this naming scheme somewhat weird. > A virtio disk shows up as a regular PCI function on the PCI > bus side by side with other (non-virtio) devices. The naming otoh > suggests that virtio-pci is a subsystem of its own, which is simply > incorrect from a by-path perspective. > > Using just the plain PCI path id is actually sufficient to identify > a virtio disk by its path. This would be in line with virtio > network interface path names which use the plain PCI naming. > > One could argue about back-level compatibility, but virtio by-path > naming has changed multiple times. We have seen virtio-pci-virtio<n> > (not predictable), pci-<busid> and virtio-pci-<busid> already. It > might be a good time now to settle on a common approach for all > virtio types. > > For the reasons above, I'd vote for <subsystem>-<busid>, which > would work for PCI and CCW, not sure about ARM MMIO though. > Opinions? So, to make this clear, we in systemd are kinda interested in splitting out these virtio helpers into some external project maintained by virtio peopl. We as systemd/udev maintainers have very little understanding of the underlying technology, so we can't really be any good maintainers of this, and we can't really comment on this stuff, in particular when it gets more exotic, like the CCW stuff. Even better would be if the kernel would do the naming on its own, and maybe just provide us with a sysattr on the relevant devices that we can read to determine the path from, so that we don#t have to maintain this at all in userspace. That way, the driver folks on the kernel side can use any naming they like without ever having to patch this into systemd or udev. This is similar to SCSI stuff and all things like that: the more exotic it gets the less place this really has in systemd, we are not the right maintainers for this. And given that this is all nicely pluggable (you can ship your own udev extensions externally very easily), there's really no reason for this to be in systemd/udev. Anyway, I fear you're going to have a hard time involving us in a technical discussions about the issue you are raising, since quite frankly we have no clue about virtio... Lennart -- Lennart Poettering, Red Hat _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
