On Fri, Feb 24, 2017 at 10:56 AM, Viktor Mihajlovski
[off-list ref] wrote:

On 20.02.2017 17:00, Cornelia Huck wrote:

quoted

On Mon, 20 Feb 2017 15:34:49 +0100
Viktor Mihajlovski [off-list ref] wrote:

quoted

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.

quoted

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.

quoted

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@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization