[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC] MAINTAINERS: split out s390x sections
From: |
Cornelia Huck |
Subject: |
Re: [PATCH RFC] MAINTAINERS: split out s390x sections |
Date: |
Tue, 21 Dec 2021 17:11:58 +0100 |
User-agent: |
Notmuch/0.34 (https://notmuchmail.org) |
On Tue, Dec 21 2021, Thomas Huth <thuth@redhat.com> wrote:
> On 20/12/2021 12.54, Cornelia Huck wrote:
>> Split out some more specialized devices etc., so that we can build
>> smarter lists of people to be put on cc: in the future.
>>
>> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
>> ---
>>
>> As discussed offlist. Some notes:
>> - The new sections have inherited the maintainers of the sections
>> they have been split out of (except where people had already
>> volunteered). That's easy to change, obviously, and I hope that
>> the cc: list already contains people who might have interest in
>> volunteering for some sections.
>> - I may not have gotten the F: patterns correct, please double check.
>> - I'm also not sure about where in the MAINTAINERS file the new
>> sections should go; if you have a better idea, please speak up.
>> - Also, if you have better ideas regarding the sections, please
>> speak up as well :)
>> - Pull requests will probably continue the same way as now (i.e.
>> patches picked up at the top level and then sent, except for some
>> things like tcg which may go separately.) Not sure if it would
>> make sense to try out the submaintainer pull request model again,
>> I don't think it made life easier in the past, and now we have
>> the b4 tool to pick patches easily anyway. It might be a good
>> idea to check which of the tree locations should stay, or if we
>> want to have new ones.
>>
>> ---
>> MAINTAINERS | 86 ++++++++++++++++++++++++++++++++++++++++++++++-------
>> 1 file changed, 75 insertions(+), 11 deletions(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 9a8d1bdf727d..d1916f075386 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -297,7 +297,6 @@ M: David Hildenbrand <david@redhat.com>
>> S: Maintained
>> F: target/s390x/
>> F: target/s390x/tcg
>> -F: target/s390x/cpu_models_*.[ch]
>> F: hw/s390x/
>> F: disas/s390.c
>> F: tests/tcg/s390x/
>> @@ -396,16 +395,10 @@ M: Halil Pasic <pasic@linux.ibm.com>
>> M: Christian Borntraeger <borntraeger@linux.ibm.com>
>> S: Supported
>> F: target/s390x/kvm/
>> -F: target/s390x/ioinst.[ch]
>> F: target/s390x/machine.c
>> F: target/s390x/sigp.c
>> -F: target/s390x/cpu_features*.[ch]
>> -F: target/s390x/cpu_models.[ch]
>> F: hw/s390x/pv.c
>> F: include/hw/s390x/pv.h
>> -F: hw/intc/s390_flic.c
>> -F: hw/intc/s390_flic_kvm.c
>> -F: include/hw/s390x/s390_flic.h
>> F: gdb-xml/s390*.xml
>> T: git https://github.com/borntraeger/qemu.git s390-next
>> L: qemu-s390x@nongnu.org
>> @@ -1529,12 +1522,8 @@ S390 Virtio-ccw
>> M: Halil Pasic <pasic@linux.ibm.com>
>> M: Christian Borntraeger <borntraeger@linux.ibm.com>
>> S: Supported
>> -F: hw/char/sclp*.[hc]
>> -F: hw/char/terminal3270.c
>> F: hw/s390x/
>> F: include/hw/s390x/
>> -F: hw/watchdog/wdt_diag288.c
>> -F: include/hw/watchdog/wdt_diag288.h
>> F: configs/devices/s390x-softmmu/default.mak
>> F: tests/avocado/machine_s390_ccw_virtio.py
>> T: git https://github.com/borntraeger/qemu.git s390-next
>> @@ -1559,6 +1548,80 @@ F: hw/s390x/s390-pci*
>> F: include/hw/s390x/s390-pci*
>> L: qemu-s390x@nongnu.org
>>
>> +S390 channel subsystem
>> +M: Halil Pasic <pasic@linux.ibm.com>
>> +M: Christian Borntraeger <borntraeger@linux.ibm.com>
>> +S: Supported
>> +F: hw/s390x/ccw-device.[ch]
>> +F: hw/s390x/css.c
>> +F: hw/s390x/css-bridge.c
>> +F: include/hw/s390x/css.h
>> +F: include/hw/s390x/css-bridge.h
>> +F: include/hw/s390x/ioinst.h
>> +F: target/s390x/ioinst.c
>> +L: qemu-s390x@nongnu.org
>> +
>> +3270 device
>> +M: Halil Pasic <pasic@linux.ibm.com>
>> +M: Christian Borntraeger <borntraeger@linux.ibm.com>
>> +S: Odd fixes
>> +F: include/hw/s390x/3270-ccw.h
>> +F: hw/char/terminal3270.c
>> +F: hw/s390x/3270-ccw.c
>> +L: qemu-s390x@nongnu.org
>
> I'm a little bit torn between putting the s390x-related devices here in the
> "Machine" section (which should rather be used for machines and not for
> devices), or in the more generic "Devices" section later in the MAINTAINERS
> file. We already have vfio-ccw and vfio-ap in the "Devices" section, so
> maybe we should put the other s390x-related devices there as well? (maybe
> with a "s390x" prefix so that they show up in the same spot if we sort them
> alphabetically?)
We also have virtio-ccw there already. (I'm not sure whether the
"Devices" section is actually supposed to be ordered alphabetically; if
it is, I think it would need some reordering effort.)
For clarity, we could still add an S390 prefix here...
>
>> +diag 288 watchdog
>> +M: Halil Pasic <pasic@linux.ibm.com>
>> +M: Christian Borntraeger <borntraeger@linux.ibm.com>
>> +S: Supported
>> +F: hw/watchdog/wdt_diag288.c
>> +F: include/hw/watchdog/wdt_diag288.h
>> +L: qemu-s390x@nongnu.org
...and here.
>> +
>> +S390 CPU models
>> +M: David Hildenbrand <david@redhat.com>
>> +S: Maintained
>> +F: target/s390x/cpu_features*.[ch]
>> +F: target/s390x/cpu_models.[ch]
>> +L: qemu-s390x@nongnu.org
This one was hard to fit, because it spans tcg and kvm, so we should
probably keep it here.
>> +
>> +S390 storage key device
>> +M: Halil Pasic <pasic@linux.ibm.com>
>> +M: Christian Borntraeger <borntraeger@linux.ibm.com>
>> +S: Supported
>> +F: hw/s390x/storage-keys.h
>> +F: hw/390x/s390-skeys*.c
>> +L: qemu-s390x@nongnu.org
>> +
>> +S390 storage attribute device
>> +M: Halil Pasic <pasic@linux.ibm.com>
>> +M: Christian Borntraeger <borntraeger@linux.ibm.com>
>> +S: Supported
>> +F: hw/s390x/storage-attributes.h
>> +F: hw/s390/s390-stattrib*.c
>> +L: qemu-s390x@nongnu.org
These two could go to the devices section.
>> +
>> +S390 SCLP-backed devices
>> +M: Halil Pasic <pasic@linux.ibm.com>
>> +M: Christian Borntraeger <borntraeger@linux.ibm.com>
>> +S: Supported
>> +F: include/hw/s390x/event-facility.h
>> +F: include/hw/s390x/sclp.h
>> +F: hw/char/sclp*.[hc]
>> +F: hw/s390x/event-facility.c
>> +F: hw/s390x/sclp*.c
>> +L: qemu-s390x@nongnu.org
I'd rather keep this one here, as it contains not only the console
devices, but also the whole infrastructure. (Hmm, maybe call this
"devices and infrastructure"? </bikeshed>)
>> +
>> +S390 floating interrupt controller
>> +M: Halil Pasic <pasic@linux.ibm.com>
>> +M: Christian Borntraeger <borntraeger@linux.ibm.com>
>> +M: David Hildenbrand <david@redhat.com>
>> +S: Supported
>> +F: hw/intc/s390_flic.c
>> +F: hw/intc/s390_flic_kvm.c
>
> The above two lines could be shortened to:
>
> F: hw/intc/s390_flic*.c
Yeah, this was simple cut-and-paste :)
(This section could also move.)
>
>> +F: include/hw/s390x/s390_flic.h
>> +L: qemu-s390x@nongnu.org
>> +
>> X86 Machines
>> ------------
>> PC
>> @@ -1957,6 +2020,7 @@ M: Halil Pasic <pasic@linux.ibm.com>
>> S: Supported
>> F: hw/s390x/virtio-ccw*.[hc]
>> F: hw/s390x/vhost-vsock-ccw.c
>> +F: hw/s390x/vhost-user-fs-ccw.c
>> T: git https://gitlab.com/cohuck/qemu.git s390-next
>> T: git https://github.com/borntraeger/qemu.git s390-next
>> L: qemu-s390x@nongnu.org
>
> I'm also fine with this patch without further modifications, so:
>
> Acked-by: Thomas Huth <thuth@redhat.com>
Thanks!
Any objections if I move the sections as outlined above and keep the
acks I already have?
- [PATCH RFC] MAINTAINERS: split out s390x sections, Cornelia Huck, 2021/12/20
- Re: [PATCH RFC] MAINTAINERS: split out s390x sections, Philippe Mathieu-Daudé, 2021/12/20
- Re: [PATCH RFC] MAINTAINERS: split out s390x sections, David Hildenbrand, 2021/12/20
- Re: [PATCH RFC] MAINTAINERS: split out s390x sections, Christian Borntraeger, 2021/12/21
- Re: [PATCH RFC] MAINTAINERS: split out s390x sections, Thomas Huth, 2021/12/21
- Re: [PATCH RFC] MAINTAINERS: split out s390x sections,
Cornelia Huck <=
- Re: [PATCH RFC] MAINTAINERS: split out s390x sections, Halil Pasic, 2021/12/21