All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
To: Michal Sekletar <msekleta@redhat.com>
Cc: systemd-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org
Subject: Re: udev virtio by-path naming
Date: Fri, 24 Feb 2017 10:56:28 +0100	[thread overview]
Message-ID: <9cb1f5ff-0a5b-4d0a-16f6-887c7658795a@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170220170041.68c9bf4f.cornelia.huck@de.ibm.com>

On 20.02.2017 17:00, Cornelia Huck wrote:
> On Mon, 20 Feb 2017 15:34:49 +0100
> Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> 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?

-- 

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

  reply	other threads:[~2017-02-24  9:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <de55b0f4-4582-cf06-4b0d-12c2282406a8@linux.vnet.ibm.com>
2017-02-20 15:14 ` [systemd-devel] udev virtio by-path naming Lennart Poettering
2017-02-20 16:00 ` Cornelia Huck
2017-02-24  9:56   ` Viktor Mihajlovski [this message]
2017-02-27 11:22     ` Michal Sekletar
     [not found]     ` <CALVzVJZhZTNbZp1EB9cT82YxUnbUZZ+ZPo7Od8CWz5C3faN1AA@mail.gmail.com>
2017-02-28  8:47       ` Viktor Mihajlovski
2017-03-01  3:30         ` [systemd-devel] " Zbigniew Jędrzejewski-Szmek
     [not found]         ` <20170301033007.GG29552@in.waw.pl>
2017-03-01 15:02           ` Viktor Mihajlovski
     [not found]           ` <7de4f313-d3a6-b50d-4e53-3b01d6f0f2a0@linux.vnet.ibm.com>
2017-03-01 15:58             ` Daniel P. Berrange
2017-03-01 16:24               ` Daniel P. Berrange
2017-03-01 18:28               ` Viktor Mihajlovski
     [not found]               ` <f6dfe52a-4332-90fc-a426-712453a8c382@linux.vnet.ibm.com>
2017-03-01 18:44                 ` Daniel P. Berrange
     [not found]                 ` <20170301184439.GS10160@redhat.com>
2017-03-01 19:23                   ` Viktor Mihajlovski
     [not found]                   ` <79e0b5c0-0860-81b2-cd4d-6efaca924bcc@linux.vnet.ibm.com>
2017-03-01 20:02                     ` Viktor Mihajlovski
     [not found] ` <20170220151432.GA15888@gardel-login>
2017-02-28 19:28   ` Daniel P. Berrange
     [not found]   ` <20170228192851.GC10067@redhat.com>
2017-02-28 19:39     ` Lennart Poettering
2017-03-01  3:43       ` Zbigniew Jędrzejewski-Szmek
     [not found]       ` <20170301034321.GH29552@in.waw.pl>
2017-03-01  3:51         ` Andrei Borzenkov
     [not found]         ` <559a5978-6957-49cd-2ec7-79897732be95@gmail.com>
2017-03-01  4:27           ` Zbigniew Jędrzejewski-Szmek
2017-02-20 14:34 Viktor Mihajlovski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9cb1f5ff-0a5b-4d0a-16f6-887c7658795a@linux.vnet.ibm.com \
    --to=mihajlov@linux.vnet.ibm.com \
    --cc=msekleta@redhat.com \
    --cc=systemd-devel@lists.freedesktop.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.