* Re: [systemd-devel] udev virtio by-path naming [not found] <de55b0f4-4582-cf06-4b0d-12c2282406a8@linux.vnet.ibm.com> @ 2017-02-20 15:14 ` Lennart Poettering 2017-02-20 16:00 ` Cornelia Huck [not found] ` <20170220151432.GA15888@gardel-login> 2 siblings, 0 replies; 18+ messages in thread From: Lennart Poettering @ 2017-02-20 15:14 UTC (permalink / raw) To: Viktor Mihajlovski; +Cc: systemd-devel, virtualization On Mon, 20.02.17 15:34, Viktor Mihajlovski (mihajlov@linux.vnet.ibm.com) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: udev virtio by-path naming [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 [not found] ` <20170220151432.GA15888@gardel-login> 2 siblings, 1 reply; 18+ messages in thread From: Cornelia Huck @ 2017-02-20 16:00 UTC (permalink / raw) To: Viktor Mihajlovski; +Cc: systemd-devel, virtualization 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: udev virtio by-path naming 2017-02-20 16:00 ` Cornelia Huck @ 2017-02-24 9:56 ` Viktor Mihajlovski 2017-02-27 11:22 ` Michal Sekletar [not found] ` <CALVzVJZhZTNbZp1EB9cT82YxUnbUZZ+ZPo7Od8CWz5C3faN1AA@mail.gmail.com> 0 siblings, 2 replies; 18+ messages in thread From: Viktor Mihajlovski @ 2017-02-24 9:56 UTC (permalink / raw) To: Michal Sekletar; +Cc: systemd-devel, virtualization 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: udev virtio by-path naming 2017-02-24 9:56 ` Viktor Mihajlovski @ 2017-02-27 11:22 ` Michal Sekletar [not found] ` <CALVzVJZhZTNbZp1EB9cT82YxUnbUZZ+ZPo7Od8CWz5C3faN1AA@mail.gmail.com> 1 sibling, 0 replies; 18+ messages in thread From: Michal Sekletar @ 2017-02-27 11:22 UTC (permalink / raw) To: Viktor Mihajlovski; +Cc: systemd-devel, virtualization On Fri, Feb 24, 2017 at 10:56 AM, Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> wrote: > 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? 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <CALVzVJZhZTNbZp1EB9cT82YxUnbUZZ+ZPo7Od8CWz5C3faN1AA@mail.gmail.com>]
* Re: udev virtio by-path naming [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> 0 siblings, 2 replies; 18+ messages in thread From: Viktor Mihajlovski @ 2017-02-28 8:47 UTC (permalink / raw) To: Michal Sekletar; +Cc: systemd-devel, virtualization On 27.02.2017 12:22, Michal Sekletar wrote: > On Fri, Feb 24, 2017 at 10:56 AM, Viktor Mihajlovski > <mihajlov@linux.vnet.ibm.com> wrote: >> 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? > > 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. Thanks for taking the time to explain the background. As it happens, I have a local patch to produce virtio-<subsystem>-<systemid> symlinks as you suggested. However, I wasn't really happy about that for two reasons: 1. The s390x architecture has native disks that show up as devices on the bus, so it is possible to create persistent symlinks based solely on the bus id, irrespective of the disk type (virtio or dasd). This helps in defining OS images that can run on native and paravirtualized disk setups. Which is broken now. This might be considered an architecture one-off, but 2. SCSI disk pathids are generally represented as <hba-busid>-<scsi-lun> (the lun in hba specific notation). For a generic/parallel SCSI HBA the path id will always be in a format like pci-0000:00:03.0-scsi-0:0:0:0 except for the virtio HBA, which would look like this virtio-pci-0000:00:03.0-scsi-0:0:0:0 This makes even less sense to me (even if there are probably no more generic SCSI adapters to be found in the wild). My fear is that by dodging a potential inconvenience for the users much more pain will arise further down the road whenever a new virtio device type shows up. My take would rather be to produce semantically correct builtin path ids and have the distributions add their custom rules for virtio-blk if they are wanted. > > 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 >> > -- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [systemd-devel] udev virtio by-path naming 2017-02-28 8:47 ` Viktor Mihajlovski @ 2017-03-01 3:30 ` Zbigniew Jędrzejewski-Szmek [not found] ` <20170301033007.GG29552@in.waw.pl> 1 sibling, 0 replies; 18+ messages in thread From: Zbigniew Jędrzejewski-Szmek @ 2017-03-01 3:30 UTC (permalink / raw) To: Viktor Mihajlovski; +Cc: systemd-devel, Michal Sekletar, virtualization On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: > >>>> 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. It seems that there's agreement that <subsystem>-<busid> is the right approach. Ideally we would keep the virtio-pci-<busid> links as they appear right now, for backwards compatibility, just for the pci devices, and mark them as deprecated (dunno where, maybe just in NEWS), and add the code to make the links. I haven't looked at the code, maybe we just do this with the right udev rule, and also stick the deprecation comment there? Zbyszek ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <20170301033007.GG29552@in.waw.pl>]
* Re: [systemd-devel] udev virtio by-path naming [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> 1 sibling, 0 replies; 18+ messages in thread From: Viktor Mihajlovski @ 2017-03-01 15:02 UTC (permalink / raw) To: Zbigniew Jędrzejewski-Szmek Cc: Daniel P. Berrange, systemd-devel, Michal Sekletar, virtualization On 01.03.2017 04:30, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: >>>>>> 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. > > It seems that there's agreement that <subsystem>-<busid> is the right > approach. > > Ideally we would keep the virtio-pci-<busid> links as they appear > right now, for backwards compatibility, just for the pci devices, and > mark them as deprecated (dunno where, maybe just in NEWS), and add the > code to make the links. > > I haven't looked at the code, maybe we just do this with the right > udev rule, and also stick the deprecation comment there? > > Zbyszek > I've posted a github pull request [1], and would appreciate review feedback. As I am lacking an ARM setup, it would also be nice if someone with ARM skills could have a look as well. If wanted, I can take a stab at virtio-mmio, but would need the output of udevadm -a /dev/vda from a virtio-mmio system. [1] https://github.com/systemd/systemd/pull/5500 -- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <7de4f313-d3a6-b50d-4e53-3b01d6f0f2a0@linux.vnet.ibm.com>]
* Re: [systemd-devel] udev virtio by-path naming [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 ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Daniel P. Berrange @ 2017-03-01 15:58 UTC (permalink / raw) To: Viktor Mihajlovski Cc: systemd-devel, Zbigniew Jędrzejewski-Szmek, Michal Sekletar, virtualization On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote: > On 01.03.2017 04:30, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: > >>>>>> 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. > > > > It seems that there's agreement that <subsystem>-<busid> is the right > > approach. > > > > Ideally we would keep the virtio-pci-<busid> links as they appear > > right now, for backwards compatibility, just for the pci devices, and > > mark them as deprecated (dunno where, maybe just in NEWS), and add the > > code to make the links. > > > > I haven't looked at the code, maybe we just do this with the right > > udev rule, and also stick the deprecation comment there? > > > > Zbyszek > > > I've posted a github pull request [1], and would appreciate review > feedback. As I am lacking an ARM setup, it would also be nice if someone > with ARM skills could have a look as well. FYI you can install ARM7 guests on an x86_64 host, using pre-built Fedora images https://fedoraproject.org/wiki/QA:Testcase_Virt_ARM_on_x86 NB, this will install the guest using virtio-pci. So if you want to see virtio-mmio in action, you'll need to edit the libvirt XML config afterwards to add another disk, eg <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/data.qcow2'/> <target dev='vda' bus='virtio'/> <address type='virtio-mmio'/> </disk> > If wanted, I can take a stab at virtio-mmio, but would need the output > of udevadm -a /dev/vda from a virtio-mmio system. Presumably you mean 'udevadm info -a /dev/vda' ? That reports the following, given a basic Fedora 25 guest, with a virtio-mmio disk added as per the guide above... looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda': KERNEL=="vda" SUBSYSTEM=="block" DRIVER=="" ATTR{alignment_offset}=="0" ATTR{badblocks}=="" ATTR{cache_type}=="write back" ATTR{capability}=="50" ATTR{discard_alignment}=="0" ATTR{ext_range}=="256" ATTR{inflight}==" 0 0" ATTR{range}=="16" ATTR{removable}=="0" ATTR{ro}=="0" ATTR{serial}=="" ATTR{size}=="2097152" ATTR{stat}==" 94 0 4208 285 0 0 0 0 0 100 280" looking at parent device '/devices/platform/a003e00.virtio_mmio/virtio3': KERNELS=="virtio3" SUBSYSTEMS=="virtio" DRIVERS=="virtio_blk" ATTRS{device}=="0x0002" ATTRS{features}=="0010101101110000000000000000110000000000000000000000000000 000000" ATTRS{status}=="0x00000007" ATTRS{vendor}=="0x554d4551" looking at parent device '/devices/platform/a003e00.virtio_mmio': KERNELS=="a003e00.virtio_mmio" SUBSYSTEMS=="platform" DRIVERS=="virtio-mmio" ATTRS{driver_override}=="(null)" looking at parent device '/devices/platform': KERNELS=="platform" SUBSYSTEMS=="" DRIVERS=="" Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [systemd-devel] udev virtio by-path naming 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> 2 siblings, 0 replies; 18+ messages in thread From: Daniel P. Berrange @ 2017-03-01 16:24 UTC (permalink / raw) To: Viktor Mihajlovski; +Cc: systemd-devel, virtualization On Wed, Mar 01, 2017 at 03:58:12PM +0000, Daniel P. Berrange wrote: > On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote: > > If wanted, I can take a stab at virtio-mmio, but would need the output > > of udevadm -a /dev/vda from a virtio-mmio system. > > Presumably you mean 'udevadm info -a /dev/vda' ? That reports the following, > given a basic Fedora 25 guest, with a virtio-mmio disk added as per the > guide above... > > looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda': BTW, the hex digits in here are the virtio mmio address which changes per device eg if i have 3 virtio-mmio backed disks, I get looking at device '/devices/platform/a003a00.virtio_mmio/virtio3/block/vda': looking at device '/devices/platform/a003c00.virtio_mmio/virtio4/block/vdb': looking at device '/devices/platform/a003e00.virtio_mmio/virtio5/block/vdc': Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [systemd-devel] udev virtio by-path naming 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> 2 siblings, 0 replies; 18+ messages in thread From: Viktor Mihajlovski @ 2017-03-01 18:28 UTC (permalink / raw) To: Daniel P. Berrange Cc: systemd-devel, Zbigniew Jędrzejewski-Szmek, Michal Sekletar, virtualization On 01.03.2017 16:58, Daniel P. Berrange wrote: > On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote: >> On 01.03.2017 04:30, Zbigniew Jędrzejewski-Szmek wrote: >>> On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: >>>>>>>> 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. >>> >>> It seems that there's agreement that <subsystem>-<busid> is the right >>> approach. >>> >>> Ideally we would keep the virtio-pci-<busid> links as they appear >>> right now, for backwards compatibility, just for the pci devices, and >>> mark them as deprecated (dunno where, maybe just in NEWS), and add the >>> code to make the links. >>> >>> I haven't looked at the code, maybe we just do this with the right >>> udev rule, and also stick the deprecation comment there? >>> >>> Zbyszek >>> >> I've posted a github pull request [1], and would appreciate review >> feedback. As I am lacking an ARM setup, it would also be nice if someone >> with ARM skills could have a look as well. > > FYI you can install ARM7 guests on an x86_64 host, using pre-built Fedora > images > > https://fedoraproject.org/wiki/QA:Testcase_Virt_ARM_on_x86 > > NB, this will install the guest using virtio-pci. So if you want to > see virtio-mmio in action, you'll need to edit the libvirt XML config > afterwards to add another disk, eg > > <disk type='file' device='disk'> > <driver name='qemu' type='qcow2'/> > <source file='/var/lib/libvirt/images/data.qcow2'/> > <target dev='vda' bus='virtio'/> > <address type='virtio-mmio'/> > </disk> > > I might be stuck with a too old QEMU binary, the guest panics as soon as the virtio-mmio module is loaded. If I drop to the dracut debug shell I can see at least a number of mmio address slots(?) ranging from a000000.virtio_mmio to a003e00.virtio_mmio. >> If wanted, I can take a stab at virtio-mmio, but would need the output >> of udevadm -a /dev/vda from a virtio-mmio system. > > Presumably you mean 'udevadm info -a /dev/vda' ? That reports the following, yes, I always have to type the command twice :-( > given a basic Fedora 25 guest, with a virtio-mmio disk added as per the > guide above... > > looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda': > KERNEL=="vda" > SUBSYSTEM=="block" > DRIVER=="" > ATTR{alignment_offset}=="0" > ATTR{badblocks}=="" > ATTR{cache_type}=="write back" > ATTR{capability}=="50" > ATTR{discard_alignment}=="0" > ATTR{ext_range}=="256" > ATTR{inflight}==" 0 0" > ATTR{range}=="16" > ATTR{removable}=="0" > ATTR{ro}=="0" > ATTR{serial}=="" > ATTR{size}=="2097152" > ATTR{stat}==" 94 0 4208 285 0 0 0 > 0 0 100 280" > > looking at parent device '/devices/platform/a003e00.virtio_mmio/virtio3': > KERNELS=="virtio3" > SUBSYSTEMS=="virtio" > DRIVERS=="virtio_blk" > ATTRS{device}=="0x0002" > ATTRS{features}=="0010101101110000000000000000110000000000000000000000000000 > 000000" > ATTRS{status}=="0x00000007" > ATTRS{vendor}=="0x554d4551" > > looking at parent device '/devices/platform/a003e00.virtio_mmio': > KERNELS=="a003e00.virtio_mmio" > SUBSYSTEMS=="platform" > DRIVERS=="virtio-mmio" > ATTRS{driver_override}=="(null)" Since I can't do that on my box, would you be so kind to run ls -l /dev/disk/by-path If it returns ids like virtio-pci-a003e00.virtio_mmio[-partn] my suggested patch should be OK for ARM in that it will produce ids in the format platform-a003e00.virtio_mmio[-partn] > > looking at parent device '/devices/platform': > KERNELS=="platform" > SUBSYSTEMS=="" > DRIVERS=="" > > > > Regards, > Daniel > -- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <f6dfe52a-4332-90fc-a426-712453a8c382@linux.vnet.ibm.com>]
* Re: [systemd-devel] udev virtio by-path naming [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> 1 sibling, 0 replies; 18+ messages in thread From: Daniel P. Berrange @ 2017-03-01 18:44 UTC (permalink / raw) To: Viktor Mihajlovski Cc: systemd-devel, Zbigniew Jędrzejewski-Szmek, Michal Sekletar, virtualization On Wed, Mar 01, 2017 at 07:28:46PM +0100, Viktor Mihajlovski wrote: > On 01.03.2017 16:58, Daniel P. Berrange wrote: > > given a basic Fedora 25 guest, with a virtio-mmio disk added as per the > > guide above... > > > > looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda': > > KERNEL=="vda" > > SUBSYSTEM=="block" > > DRIVER=="" > > ATTR{alignment_offset}=="0" > > ATTR{badblocks}=="" > > ATTR{cache_type}=="write back" > > ATTR{capability}=="50" > > ATTR{discard_alignment}=="0" > > ATTR{ext_range}=="256" > > ATTR{inflight}==" 0 0" > > ATTR{range}=="16" > > ATTR{removable}=="0" > > ATTR{ro}=="0" > > ATTR{serial}=="" > > ATTR{size}=="2097152" > > ATTR{stat}==" 94 0 4208 285 0 0 0 > > 0 0 100 280" > > > > looking at parent device '/devices/platform/a003e00.virtio_mmio/virtio3': > > KERNELS=="virtio3" > > SUBSYSTEMS=="virtio" > > DRIVERS=="virtio_blk" > > ATTRS{device}=="0x0002" > > ATTRS{features}=="0010101101110000000000000000110000000000000000000000000000 > > 000000" > > ATTRS{status}=="0x00000007" > > ATTRS{vendor}=="0x554d4551" > > > > looking at parent device '/devices/platform/a003e00.virtio_mmio': > > KERNELS=="a003e00.virtio_mmio" > > SUBSYSTEMS=="platform" > > DRIVERS=="virtio-mmio" > > ATTRS{driver_override}=="(null)" > Since I can't do that on my box, would you be so kind to run > ls -l /dev/disk/by-path > If it returns ids like > virtio-pci-a003e00.virtio_mmio[-partn] > my suggested patch should be OK for ARM in that it will produce ids in > the format > platform-a003e00.virtio_mmio[-partn] Ok, my guest has 4 disks - sda - virtio-scsi, over virtio-pci transport - sdb - virtio-scsi, over virtio-mmio transport - vda - virtio-scsi, over virtio-pci transport - vdb - virtio-scsi, over virtio-mmio transport with systemd 231 I get these links platform-3f000000.pcie-pci-0000:00:01.1-virtio-pci-0000:02:00.0-scsi-0:0:0:0 -> ../../sda platform-3f000000.pcie-pci-0000:00:01.3-virtio-pci-0000:04:00.0 -> ../../vda virtio-pci-a003c00.virtio_mmio -> ../../vdb virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb after applying your patch I get these links: platform-3f000000.pcie-pci-0000:00:01.1-virtio-pci-0000:02:00.0-scsi-0:0:0:0 -> ../../sda platform-3f000000.pcie-pci-0000:00:01.3-virtio-pci-0000:04:00.0 -> ../../vda platform-3f000000.pcie-pci-0000:02:00.0-scsi-0:0:0:0 -> ../../sda platform-3f000000.pcie-pci-0000:04:00.0 -> ../../vda platform-a003c00.virtio_mmio -> ../../vdb platform-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb virtio-pci-a003c00.virtio_mmio -> ../../vdb virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb So that appears to be working as designed - the 4 backcompat symlinks are still there, and the new symlinks all live under the platform- prefix and don't have a bogus 'pci' in the name for mmio links Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <20170301184439.GS10160@redhat.com>]
* Re: [systemd-devel] udev virtio by-path naming [not found] ` <20170301184439.GS10160@redhat.com> @ 2017-03-01 19:23 ` Viktor Mihajlovski [not found] ` <79e0b5c0-0860-81b2-cd4d-6efaca924bcc@linux.vnet.ibm.com> 1 sibling, 0 replies; 18+ messages in thread From: Viktor Mihajlovski @ 2017-03-01 19:23 UTC (permalink / raw) To: Daniel P. Berrange Cc: systemd-devel, Zbigniew Jędrzejewski-Szmek, Michal Sekletar, virtualization On 01.03.2017 19:44, Daniel P. Berrange wrote: [...] replying on the list, a bit lengthy > > Ok, my guest has 4 disks > > - sda - virtio-scsi, over virtio-pci transport > - sdb - virtio-scsi, over virtio-mmio transport > - vda - virtio-scsi, over virtio-pci transport > - vdb - virtio-scsi, over virtio-mmio transport > > with systemd 231 I get these links > > platform-3f000000.pcie-pci-0000:00:01.1-virtio-pci-0000:02:00.0-scsi-0:0:0:0 -> ../../sda > platform-3f000000.pcie-pci-0000:00:01.3-virtio-pci-0000:04:00.0 -> ../../vda this is somewhat suprising (the pcie-pci-xxxx part), could you once more do me a favor and run udevadm info -a /dev/vda and paste the output? > virtio-pci-a003c00.virtio_mmio -> ../../vdb > virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb > > after applying your patch I get these links: > > platform-3f000000.pcie-pci-0000:00:01.1-virtio-pci-0000:02:00.0-scsi-0:0:0:0 -> ../../sda > platform-3f000000.pcie-pci-0000:00:01.3-virtio-pci-0000:04:00.0 -> ../../vda well, these are probably stale links from the old systemd baked into your initrd > platform-3f000000.pcie-pci-0000:02:00.0-scsi-0:0:0:0 -> ../../sda > platform-3f000000.pcie-pci-0000:04:00.0 -> ../../vda I don't yet understand these, especially why the intermediate pci-xxxx id has vanished > platform-a003c00.virtio_mmio -> ../../vdb > platform-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb these look as expected > virtio-pci-a003c00.virtio_mmio -> ../../vdb > virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb stale > > So that appears to be working as designed - the 4 backcompat symlinks are > still there, and the new symlinks all live under the platform- prefix > and don't have a bogus 'pci' in the name for mmio links the patch only provide compat symlinks for the pci path ids traditionally seen on x86 systems, but I think we don't want those for platforms other than x86, right? > > Regards, > Daniel > -- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <79e0b5c0-0860-81b2-cd4d-6efaca924bcc@linux.vnet.ibm.com>]
* Re: [systemd-devel] udev virtio by-path naming [not found] ` <79e0b5c0-0860-81b2-cd4d-6efaca924bcc@linux.vnet.ibm.com> @ 2017-03-01 20:02 ` Viktor Mihajlovski 0 siblings, 0 replies; 18+ messages in thread From: Viktor Mihajlovski @ 2017-03-01 20:02 UTC (permalink / raw) To: Daniel P. Berrange Cc: systemd-devel, Zbigniew Jędrzejewski-Szmek, Michal Sekletar, virtualization On 01.03.2017 20:23, Viktor Mihajlovski wrote: > On 01.03.2017 19:44, Daniel P. Berrange wrote: > [...] > replying on the list, a bit lengthy >> >> Ok, my guest has 4 disks >> >> - sda - virtio-scsi, over virtio-pci transport >> - sdb - virtio-scsi, over virtio-mmio transport >> - vda - virtio-scsi, over virtio-pci transport >> - vdb - virtio-scsi, over virtio-mmio transport >> >> with systemd 231 I get these links >> >> platform-3f000000.pcie-pci-0000:00:01.1-virtio-pci-0000:02:00.0-scsi-0:0:0:0 -> ../../sda >> platform-3f000000.pcie-pci-0000:00:01.3-virtio-pci-0000:04:00.0 -> ../../vda > this is somewhat suprising (the pcie-pci-xxxx part), could you once more > do me a favor and run > udevadm info -a /dev/vda > and paste the output? nevermind, I think I get it now, the PCI bus is a child to the platform bus, and the virtio PCI functions are connected via PCI bridges 0000:00:01.1 and 0000:00:01.3 >> virtio-pci-a003c00.virtio_mmio -> ../../vdb >> virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb >> >> after applying your patch I get these links: >> >> platform-3f000000.pcie-pci-0000:00:01.1-virtio-pci-0000:02:00.0-scsi-0:0:0:0 -> ../../sda >> platform-3f000000.pcie-pci-0000:00:01.3-virtio-pci-0000:04:00.0 -> ../../vda > well, these are probably stale links from the old systemd baked into > your initrd >> platform-3f000000.pcie-pci-0000:02:00.0-scsi-0:0:0:0 -> ../../sda >> platform-3f000000.pcie-pci-0000:04:00.0 -> ../../vda > I don't yet understand these, especially why the intermediate pci-xxxx > id has vanished that is then correct as well, because the PCI bridges don't contribute to the path id, which is a bonus effect of removing the special virtio handling I think we're good with the patch as is. [...] -- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <20170220151432.GA15888@gardel-login>]
* Re: [systemd-devel] udev virtio by-path naming [not found] ` <20170220151432.GA15888@gardel-login> @ 2017-02-28 19:28 ` Daniel P. Berrange [not found] ` <20170228192851.GC10067@redhat.com> 1 sibling, 0 replies; 18+ messages in thread From: Daniel P. Berrange @ 2017-02-28 19:28 UTC (permalink / raw) To: Lennart Poettering; +Cc: virtualization, systemd-devel On Mon, Feb 20, 2017 at 04:14:32PM +0100, Lennart Poettering wrote: > On Mon, 20.02.17 15:34, Viktor Mihajlovski (mihajlov@linux.vnet.ibm.com) 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? Virtio MMIO devices are identified by a unique control register base address. eg 0x3000. So I think <subsystem>-<busid> would work fine to all cases PCI, CCW & MMIO. Certainly it is moire correct than hardcoding virtio-pci as a prefix - that's just plain broken for non-PCI transports. > 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. The other post about ptp-kvm rules reminded me that I wanted to respond to this mail too. The problem with splitting these rules out into a separate project is that there's no other existing place that they would live. The "virtio people" as a group merely write specifications. The actual implementation of those specs is done by multiple other independant groups - QEMU (for host side, though other host side impls exist too) and Linux (for guest side). The udev rules are Linux guest support pieces, but of course Linux itself doesn't distribute udev rules - it delegated that job to the udev package hence why they are here currently. So I don't see that pushing the rules out of the udev repo would be beneficial to people building VMs. > 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... Could it be as simple as having a couple of people nominated as the technical point of contact for the virtio rules, who can be CC'd to get answers any questions that may need answering ? I don't have time to actively monitor systemd pull requests for changes affecting virtio, but I'd be ok with being pinged if issues come up that need assistance & can pull in other virt experts where needed. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <20170228192851.GC10067@redhat.com>]
* Re: [systemd-devel] udev virtio by-path naming [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> 0 siblings, 2 replies; 18+ messages in thread From: Lennart Poettering @ 2017-02-28 19:39 UTC (permalink / raw) To: Daniel P. Berrange; +Cc: virtualization, systemd-devel On Tue, 28.02.17 19:28, Daniel P. Berrange (berrange@redhat.com) wrote: > > 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. > > The other post about ptp-kvm rules reminded me that I wanted to > respond to this mail too. > > The problem with splitting these rules out into a separate project > is that there's no other existing place that they would live. The > "virtio people" as a group merely write specifications. The actual > implementation of those specs is done by multiple other independant > groups - QEMU (for host side, though other host side impls exist > too) and Linux (for guest side). The udev rules are Linux guest > support pieces, but of course Linux itself doesn't distribute udev > rules - it delegated that job to the udev package hence why they > are here currently. So I don't see that pushing the rules out of > the udev repo would be beneficial to people building VMs. > > > 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... > > Could it be as simple as having a couple of people nominated as the > technical point of contact for the virtio rules, who can be CC'd > to get answers any questions that may need answering ? I don't have > time to actively monitor systemd pull requests for changes affecting > virtio, but I'd be ok with being pinged if issues come up that need > assistance & can pull in other virt experts where needed. Well, yes, it boils down to having capable and interested maintainers for this, who know the relevant udev bits well (or at least are willing to figure out what they need ot know) and also knows virtio, and will review these patches thoroughly, make sure they following CODING_STYLE and so on.. The thing is simply that for these kinds of things it's not done with drive-by patches simply because we have noone right now who can review them with the right technical expertise. So yeah, I am not totally against leaving them in the udev repo (Or to say this differently, I am much more interested to see the scsi stuff go somewhere else than the virtion stuff), but only if somebody steps up and takes up ownership of this, and does so continously. No, this doesn't mean you have to subscribe to all systemd PRs/issues. It just means that this someone will react to being /cc'ed in the github repo sooner or later, and say something. Lennart -- Lennart Poettering, Red Hat ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [systemd-devel] udev virtio by-path naming 2017-02-28 19:39 ` Lennart Poettering @ 2017-03-01 3:43 ` Zbigniew Jędrzejewski-Szmek [not found] ` <20170301034321.GH29552@in.waw.pl> 1 sibling, 0 replies; 18+ messages in thread From: Zbigniew Jędrzejewski-Szmek @ 2017-03-01 3:43 UTC (permalink / raw) To: Lennart Poettering; +Cc: systemd-devel, Daniel P. Berrange, virtualization On Tue, Feb 28, 2017 at 08:39:07PM +0100, Lennart Poettering wrote: > On Tue, 28.02.17 19:28, Daniel P. Berrange (berrange@redhat.com) wrote: > > The problem with splitting these rules out into a separate project > > is that there's no other existing place that they would live. The > > "virtio people" as a group merely write specifications. The actual > > implementation of those specs is done by multiple other independant > > groups - QEMU (for host side, though other host side impls exist > > too) and Linux (for guest side). The udev rules are Linux guest > > support pieces, but of course Linux itself doesn't distribute udev > > rules - it delegated that job to the udev package hence why they > > are here currently. So I don't see that pushing the rules out of > > the udev repo would be beneficial to people building VMs. Yeah, that's my view too. Those by-path symlinks are parts of the basic functionality of the system, and it'd be unfortunate to require yet another package to make them appear. We've been there, done that, and too much fragmentation causes more issues than it solves. The issue with those patches seems to be that it's hard to find knowledgeable people to review them, but telling those people to start a project of their own doesn't really help with that, it just pushes the work around while adding overhead. > The thing is simply that for these kinds of things it's not done with > drive-by patches simply because we have noone right now who can review > them with the right technical expertise. > > So yeah, I am not totally against leaving them in the udev repo (Or to > say this differently, I am much more interested to see the scsi stuff > go somewhere else than the virtion stuff), but only if somebody steps > up and takes up ownership of this, and does so continously. > > No, this doesn't mean you have to subscribe to all systemd > PRs/issues. It just means that this someone will react to being /cc'ed > in the github repo sooner or later, and say something. We could keep an informal list of people who care about specific areas. This already functions to some extent, and we should just be more consistent: for any issue, see who touched the code recently, and mention them in the PR or issue, and for PRs, add people to the reviewers list. Github the social coding site, ftw! Zbyszek ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <20170301034321.GH29552@in.waw.pl>]
* Re: [systemd-devel] udev virtio by-path naming [not found] ` <20170301034321.GH29552@in.waw.pl> @ 2017-03-01 3:51 ` Andrei Borzenkov [not found] ` <559a5978-6957-49cd-2ec7-79897732be95@gmail.com> 1 sibling, 0 replies; 18+ messages in thread From: Andrei Borzenkov @ 2017-03-01 3:51 UTC (permalink / raw) To: Zbigniew Jędrzejewski-Szmek, Lennart Poettering Cc: systemd-devel, virtualization 01.03.2017 06:43, Zbigniew Jędrzejewski-Szmek пишет: > > We could keep an informal list of people who care about specific areas. MAINTAINERS file as part of systemd sources? _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <559a5978-6957-49cd-2ec7-79897732be95@gmail.com>]
* Re: [systemd-devel] udev virtio by-path naming [not found] ` <559a5978-6957-49cd-2ec7-79897732be95@gmail.com> @ 2017-03-01 4:27 ` Zbigniew Jędrzejewski-Szmek 0 siblings, 0 replies; 18+ messages in thread From: Zbigniew Jędrzejewski-Szmek @ 2017-03-01 4:27 UTC (permalink / raw) To: Andrei Borzenkov; +Cc: systemd-devel, Lennart Poettering, virtualization On Wed, Mar 01, 2017 at 06:51:17AM +0300, Andrei Borzenkov wrote: > 01.03.2017 06:43, Zbigniew Jędrzejewski-Szmek пишет: > > > > We could keep an informal list of people who care about specific areas. > > MAINTAINERS file as part of systemd sources? Heh, I really didn't want to mention this ;) I don't think MAINTAINERS as such would work. I think we'd be better off with a publicly editable wiki page somewhere on github. Zbyszek _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2017-03-01 20:02 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [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 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
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.