Re: [systemd-devel] udev virtio by-path naming

Re: [systemd-devel] udev virtio by-path naming

[Lennart Poettering]

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

Re: udev virtio by-path naming

[Cornelia Huck]

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.

Re: udev virtio by-path naming

[Viktor Mihajlovski]

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

Re: udev virtio by-path naming

[Michal Sekletar]

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

Re: udev virtio by-path naming

[Viktor Mihajlovski]

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

Re: [systemd-devel] udev virtio by-path naming

[Zbigniew Jędrzejewski-Szmek]

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

Re: [systemd-devel] udev virtio by-path naming

[Viktor Mihajlovski]

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

Re: [systemd-devel] udev virtio by-path naming

[Daniel P. Berrange]

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

Re: [systemd-devel] udev virtio by-path naming

[Daniel P. Berrange]

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/ :|

Re: [systemd-devel] udev virtio by-path naming

[Viktor Mihajlovski]

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

Re: [systemd-devel] udev virtio by-path naming

[Daniel P. Berrange]

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/ :|

Re: [systemd-devel] udev virtio by-path naming

[Viktor Mihajlovski]

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

Re: [systemd-devel] udev virtio by-path naming

[Viktor Mihajlovski]

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

Re: [systemd-devel] udev virtio by-path naming

[Daniel P. Berrange]

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/ :|

Re: [systemd-devel] udev virtio by-path naming

[Lennart Poettering]

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

Re: [systemd-devel] udev virtio by-path naming

[Zbigniew Jędrzejewski-Szmek]

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

Re: [systemd-devel] udev virtio by-path naming

[Andrei Borzenkov]

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

Re: [systemd-devel] udev virtio by-path naming

[Zbigniew Jędrzejewski-Szmek]

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