On Fri, Feb 24, 2017 at 10:56 AM, Viktor Mihajlovski <mihajlov@xxxxxxxxxxxxxxxxxx> wrote: > On 20.02.2017 17:00, Cornelia Huck wrote: >> On Mon, 20 Feb 2017 15:34:49 +0100 >> Viktor Mihajlovski <mihajlov@xxxxxxxxxxxxxxxxxx> wrote: >> >>> Hi, >>> >>> with systemd > v229 all virtio block devices will receive persistent >>> device names in the format /dev/disk-by/virtio-pci-<busid>, the >>> last component being the udev built-in path_id. >>> >>> This naming introduces some issues. >>> >>> First and obvious, there are virtio implementations not based >>> on PCI, like virtio-ccw (currently only on s390) and virtio-mmio >>> (for which I can't speak). This results in persistent names like >>> /dev/disk-by/virtio-pci-0.0.0001, where the bus id is a CCW id. >>> One seemingly obvious remedy would be to make the path_id return >>> virtio-ccw-<busid> or more generally virtio-<subsystem>-<busid>, >>> both easily done with small patches to systemd-udev. >>> >>> 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. >> >> From the ccw perspective, this is quite similar: The virtio proxy >> device shows up on the ccw bus, just like e.g. a dasd device shows up >> on the ccw bus. >> >>> >>> 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. >> >> Same for ccw: The id on the ccw bus (devno) is already unique and >> persistent. >> >>> >>> 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? >> >> I'm not sure whether there is any reason to make virtio special, >> although this depends upon what virtio-mmio looks like in the Linux >> device model (any arm folks here?) >> >> In the end, I'd be happy with any naming scheme that does not include >> 'pci' for non-pci devices. >> > Michal, as author of commit f073b1b3c0f4f0df1b0bd61042ce85fb5d27d407 > that introduced this behavior: can you comment on the reasoning for > prepending virtio- to the bus, i.e. why would pci-<busid> not > sufficiently identify the device? As with many things, it looked like a good idea at the time. In commit message I referenced discussion on upstream mailing list. In that thread we got reassured that there is one-to-one correspondence between virtio and pci devices. IIRC, we had bugs for RHEL and CentOS 7 were users requested these symlinks. Hence we went ahead with above naming scheme. Your argument about virtio being first component of the path makes sense to me, but then again, we wanted to distinguish these devices (because of user demands). In retrospect what we did wasn't probably the best we could. Nevertheless, I'd not change the naming. After all, these symlinks are for users and since then I didn't hear complains about them. I'd only adjust the code so that we produce correctly named symlinks for different parent buses (pci, ccw, mmio). IOW we would remove hardcoded "pci" string. Michal > > -- > > Mit freundlichen Grüßen/Kind Regards > Viktor Mihajlovski > > IBM Deutschland Research & Development GmbH > Vorsitzender des Aufsichtsrats: Martina Köderitz > Geschäftsführung: Dirk Wittkopp > Sitz der Gesellschaft: Böblingen > Registergericht: Amtsgericht Stuttgart, HRB 243294 > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
