* [Qemu-devel] [PATCH] MAINTAINERS: Add an entry for qemu-options* files in main directory @ 2018-05-09 5:20 Thomas Huth 2018-06-11 15:53 ` Markus Armbruster 0 siblings, 1 reply; 6+ messages in thread From: Thomas Huth @ 2018-05-09 5:20 UTC (permalink / raw) To: qemu-devel, Markus Armbruster The file "qemu-options.h", "qemu-options.hx" and "qemu-options-wrapper.h" in the main directory are currently without maintainer according to our get_maintainers.pl script. Considering that the command line options are a public interface and thus quite important, this is quite a bad state. So I'd like to suggest to add these files to the "Command line option argument parsing" section now. And since I'm interested in the command line interface of QEMU, add myself as reviewer here. Signed-off-by: Thomas Huth <thuth@redhat.com> --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index e187b1f..6aa19dc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1413,7 +1413,9 @@ F: chardev/baum.c Command line option argument parsing M: Markus Armbruster <armbru@redhat.com> +R: Thomas Huth <thuth@redhat.com> S: Supported +F: qemu-options* F: include/qemu/option.h F: tests/test-keyval.c F: tests/test-qemu-opts.c -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] MAINTAINERS: Add an entry for qemu-options* files in main directory 2018-05-09 5:20 [Qemu-devel] [PATCH] MAINTAINERS: Add an entry for qemu-options* files in main directory Thomas Huth @ 2018-06-11 15:53 ` Markus Armbruster 2018-06-12 10:46 ` Thomas Huth 0 siblings, 1 reply; 6+ messages in thread From: Markus Armbruster @ 2018-06-11 15:53 UTC (permalink / raw) To: Thomas Huth; +Cc: qemu-devel, Markus Armbruster Thomas Huth <thuth@redhat.com> writes: > The file "qemu-options.h", "qemu-options.hx" and "qemu-options-wrapper.h" > in the main directory are currently without maintainer according to our > get_maintainers.pl script. Considering that the command line options are > a public interface and thus quite important, this is quite a bad state. > So I'd like to suggest to add these files to the "Command line option > argument parsing" section now. > > And since I'm interested in the command line interface of QEMU, add > myself as reviewer here. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index e187b1f..6aa19dc 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1413,7 +1413,9 @@ F: chardev/baum.c > > Command line option argument parsing > M: Markus Armbruster <armbru@redhat.com> > +R: Thomas Huth <thuth@redhat.com> > S: Supported > +F: qemu-options* > F: include/qemu/option.h > F: tests/test-keyval.c > F: tests/test-qemu-opts.c CLI is like QMP in that there's infrastructure, interface and implementation. QMP infrastructure is MAINTAINERS sections QMP and QAPI. These are proper subsystems, with clear boundaries. Its maintainers get copied on relatively few patches. QMP infrastructure doesn't own the actual commands[1], subsystems do. For instance, the block subsystem owns commands dealing with block devices. The QMP interface is specified in the QAPI schema. Again, QMP infrastructure doesn't own it, subsystems do. However, to maintain some measure of cohesion, we co-maintain the interface: MAINTAINERS section QAPI schema covers the complete schema, and subsystems cover individual modules of the schema[2]. I think a similar arrangement make sense for CLI. We'll get it for free with CLI QAPIfication, but that'll take time. Your patch does what is possible with a monolithic interface definition: it dumps it all on one maintainer: me. I'm struggling to keep up with the QAPI schema, I'm not sure I can take more. Note that "Command line option argument parsing" is phrased carefully: it's not "CLI", not even "CLI parsing". qemu-options* does not fit there. Two solutions: widen the section so it fits better, create a new section. The latter would be closer to how we do QMP. What do you think? [1] Although QMP's qmp.c serves as a kind of dumping ground. [2] Although misc.json serves as a kind of dumping ground. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] MAINTAINERS: Add an entry for qemu-options* files in main directory 2018-06-11 15:53 ` Markus Armbruster @ 2018-06-12 10:46 ` Thomas Huth 2018-06-12 15:04 ` Paolo Bonzini 0 siblings, 1 reply; 6+ messages in thread From: Thomas Huth @ 2018-06-12 10:46 UTC (permalink / raw) To: Markus Armbruster Cc: qemu-devel, Paolo Bonzini, Eric Blake, Daniel P. Berrange On 11.06.2018 17:53, Markus Armbruster wrote: > Thomas Huth <thuth@redhat.com> writes: > >> The file "qemu-options.h", "qemu-options.hx" and "qemu-options-wrapper.h" >> in the main directory are currently without maintainer according to our >> get_maintainers.pl script. Considering that the command line options are >> a public interface and thus quite important, this is quite a bad state. >> So I'd like to suggest to add these files to the "Command line option >> argument parsing" section now. >> >> And since I'm interested in the command line interface of QEMU, add >> myself as reviewer here. >> >> Signed-off-by: Thomas Huth <thuth@redhat.com> >> --- >> MAINTAINERS | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index e187b1f..6aa19dc 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -1413,7 +1413,9 @@ F: chardev/baum.c >> >> Command line option argument parsing >> M: Markus Armbruster <armbru@redhat.com> >> +R: Thomas Huth <thuth@redhat.com> >> S: Supported >> +F: qemu-options* >> F: include/qemu/option.h >> F: tests/test-keyval.c >> F: tests/test-qemu-opts.c > > CLI is like QMP in that there's infrastructure, interface and > implementation. > > QMP infrastructure is MAINTAINERS sections QMP and QAPI. These are > proper subsystems, with clear boundaries. Its maintainers get copied on > relatively few patches. > > QMP infrastructure doesn't own the actual commands[1], subsystems do. > For instance, the block subsystem owns commands dealing with block > devices. > > The QMP interface is specified in the QAPI schema. Again, QMP > infrastructure doesn't own it, subsystems do. However, to maintain some > measure of cohesion, we co-maintain the interface: MAINTAINERS section > QAPI schema covers the complete schema, and subsystems cover individual > modules of the schema[2]. > > I think a similar arrangement make sense for CLI. We'll get it for free > with CLI QAPIfication, but that'll take time. > > Your patch does what is possible with a monolithic interface definition: > it dumps it all on one maintainer: me. I'm struggling to keep up with > the QAPI schema, I'm not sure I can take more. > > Note that "Command line option argument parsing" is phrased carefully: > it's not "CLI", not even "CLI parsing". qemu-options* does not fit > there. Two solutions: widen the section so it fits better, create a new > section. The latter would be closer to how we do QMP. > > What do you think? Both ideas sound fine to me. What about adding a new section called "Generic command line options"? I hope that the word "generic" then makes it clear that this entry is primarily thought for generic options - subsystem specific options can and should still go through the subsystem trees instead. Do you think you could still be available as (co-)maintainer of that new section? If not, who are going to be the maintainers of that new section? Paolo? Eric? Daniel? ...? Thomas ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] MAINTAINERS: Add an entry for qemu-options* files in main directory 2018-06-12 10:46 ` Thomas Huth @ 2018-06-12 15:04 ` Paolo Bonzini 2018-06-13 6:23 ` Markus Armbruster 0 siblings, 1 reply; 6+ messages in thread From: Paolo Bonzini @ 2018-06-12 15:04 UTC (permalink / raw) To: Thomas Huth, Markus Armbruster; +Cc: qemu-devel, Eric Blake, Daniel P. Berrange On 12/06/2018 12:46, Thomas Huth wrote: >> >> Your patch does what is possible with a monolithic interface definition: >> it dumps it all on one maintainer: me. I'm struggling to keep up with >> the QAPI schema, I'm not sure I can take more. >> >> Note that "Command line option argument parsing" is phrased carefully: >> it's not "CLI", not even "CLI parsing". qemu-options* does not fit >> there. Two solutions: widen the section so it fits better, create a new >> section. The latter would be closer to how we do QMP. >> >> What do you think? > Both ideas sound fine to me. What about adding a new section called > "Generic command line options"? I hope that the word "generic" then > makes it clear that this entry is primarily thought for generic options > - subsystem specific options can and should still go through the > subsystem trees instead. > > Do you think you could still be available as (co-)maintainer of that new > section? If not, who are going to be the maintainers of that new > section? Paolo? Eric? Daniel? ...? Well, currently it's going through me. I'd add vl.c too, by the way. Paolo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] MAINTAINERS: Add an entry for qemu-options* files in main directory 2018-06-12 15:04 ` Paolo Bonzini @ 2018-06-13 6:23 ` Markus Armbruster 2018-06-13 12:37 ` Paolo Bonzini 0 siblings, 1 reply; 6+ messages in thread From: Markus Armbruster @ 2018-06-13 6:23 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Thomas Huth, qemu-devel Paolo Bonzini <pbonzini@redhat.com> writes: > On 12/06/2018 12:46, Thomas Huth wrote: >> Markus Armbruster <armbru@redhat.com> writes: >>> CLI is like QMP in that there's infrastructure, interface and >>> implementation. >>> >>> QMP infrastructure is MAINTAINERS sections QMP and QAPI. These are >>> proper subsystems, with clear boundaries. Its maintainers get copied on >>> relatively few patches. >>> >>> QMP infrastructure doesn't own the actual commands[1], subsystems do. >>> For instance, the block subsystem owns commands dealing with block >>> devices. >>> >>> The QMP interface is specified in the QAPI schema. Again, QMP >>> infrastructure doesn't own it, subsystems do. However, to maintain some >>> measure of cohesion, we co-maintain the interface: MAINTAINERS section >>> QAPI schema covers the complete schema, and subsystems cover individual >>> modules of the schema[2]. >>> >>> I think a similar arrangement make sense for CLI. We'll get it for free >>> with CLI QAPIfication, but that'll take time. >>> >>> Your patch does what is possible with a monolithic interface definition: >>> it dumps it all on one maintainer: me. I'm struggling to keep up with >>> the QAPI schema, I'm not sure I can take more. >>> >>> Note that "Command line option argument parsing" is phrased carefully: >>> it's not "CLI", not even "CLI parsing". qemu-options* does not fit >>> there. Two solutions: widen the section so it fits better, create a new >>> section. The latter would be closer to how we do QMP. >>> >>> What do you think? >> Both ideas sound fine to me. What about adding a new section called >> "Generic command line options"? I hope that the word "generic" then >> makes it clear that this entry is primarily thought for generic options >> - subsystem specific options can and should still go through the >> subsystem trees instead. How well would that work in practice? get_maintainers.pl can't tell apart "generic" from "specific to subsystem S"... For QMP, get_maintainers.pl identifies the parts. Subsystem-specific parts are co-maintained by subsystem and QAPI schema maintainers, and expected to go through the subsystem tree. The "whatever remains" part is maintained just by QAPI schema maintainers, and goes through various trees in practice. Note "whatever remains" > "generic"; it's a bit of a dumping ground right now. >> Do you think you could still be available as (co-)maintainer of that new >> section? If not, who are going to be the maintainers of that new >> section? Paolo? Eric? Daniel? ...? > > Well, currently it's going through me. I'd add vl.c too, by the way. vl.c has much more than just CLI parsing. It's pushing 4kSLOC... Splitting it up would be nice. As long as it's not, I guess the pragmatic solution is to have multiple MAINTAINERS sections claim it: existing "Main loop", proposed "CLI", ... Me helping to maintain CLI in addition to some of its infrastructure would make plenty of sense if my day had 32 hours or so. Ask Marc-André what he thinks of me taking on *more* maintenance %-} ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] MAINTAINERS: Add an entry for qemu-options* files in main directory 2018-06-13 6:23 ` Markus Armbruster @ 2018-06-13 12:37 ` Paolo Bonzini 0 siblings, 0 replies; 6+ messages in thread From: Paolo Bonzini @ 2018-06-13 12:37 UTC (permalink / raw) To: Markus Armbruster; +Cc: Thomas Huth, qemu-devel On 13/06/2018 08:23, Markus Armbruster wrote: > >>> Do you think you could still be available as (co-)maintainer of that new >>> section? If not, who are going to be the maintainers of that new >>> section? Paolo? Eric? Daniel? ...? >> Well, currently it's going through me. I'd add vl.c too, by the way. > vl.c has much more than just CLI parsing. It's pushing 4kSLOC... Not much more though. There is some main loop / runstate stuff which could be split to its own file, but it's perhaps 2-300 lines of code. The rest is main() and its dependencies. Actually 1/3rd of it is main(). :) > Splitting it up would be nice. As long as it's not, I guess the > pragmatic solution is to have multiple MAINTAINERS sections claim it: > existing "Main loop", proposed "CLI", ... That would work too. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-06-13 12:37 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-05-09 5:20 [Qemu-devel] [PATCH] MAINTAINERS: Add an entry for qemu-options* files in main directory Thomas Huth 2018-06-11 15:53 ` Markus Armbruster 2018-06-12 10:46 ` Thomas Huth 2018-06-12 15:04 ` Paolo Bonzini 2018-06-13 6:23 ` Markus Armbruster 2018-06-13 12:37 ` Paolo Bonzini
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.