I think we’re talking at cross purposes, and probably we agree (not sure). I’ll top quote to try and explain my point of view.
I think there are two discussions being mixed: 1/ A discussion about improving the CLI. (Having a new one, etc etc) 2/ A discussion about supporting a low level, and complete, API that can be used by “management layers” (QAPI). I think this also gets mixed up with the discussion on migrating the CLI to use the low level API. I want to focus on the low level API. I dont see why we’re discussing a ‘high level’ thing when, for now, we have to support the CLI, and we have work to do on QAPI. If somebody wants to build a new CLI, with a new ‘high level’ interface, using QAPI - let them! Cheers Mark. > On 14 Dec 2021, at 14:48, Daniel P. Berrangé <berra...@redhat.com> wrote: > > On Tue, Dec 14, 2021 at 02:36:26PM +0100, Mark Burton wrote: >> >> >>> On 14 Dec 2021, at 14:21, Daniel P. Berrangé <berra...@redhat.com> wrote: >>> >>> On Tue, Dec 14, 2021 at 02:11:11PM +0100, Mark Burton wrote: >>>> >>>> >>>>> On 14 Dec 2021, at 14:05, Daniel P. Berrangé <berra...@redhat.com> wrote: >>>>> >>>>> On Mon, Dec 13, 2021 at 09:22:14PM +0100, Mark Burton wrote: >>>>>> >>>>>> >>>>>>> On 13 Dec 2021, at 18:59, Daniel P. Berrangé <berra...@redhat.com> >>>>>>> wrote: >>>>>>> >>>>>>> …. we no longer have to solve everything >>>>>>> Ourselves. >>>>>> >>>>>> I support this sentiment. >>>>>> >>>>>> Lets re-factor the code so people can build what they need using an API. >>>>>> Actually, ‘QEMU’ only need support the existing CLI, and provide a >>>>>> suitable internal API. >>>>>> If that API was relatively stable, that would help those (few) who >>>>>> maintain a different startup mechanism (but its only a ’nice to have’). >>>>>> (Making that convenient, as Paolo has show, would also be ’nice to >>>>>> have’). >>>>> >>>>> To be clear I do strongly believe that the QEMU project needs >>>>> to deliver the higher level simplified interface too. I just >>>>> want that higher level interface to be flexible enough to >>>>> let end users expand on what it offers, without having to >>>>> write C code nor having to switch entirely to the low level >>>>> interface like we do today. >>>>> >>>>> IOW, QEMU needs to deliver more than just a low level building >>>>> block API. >>>> >>>> Why? >>>> Clearly it would be nice if “higher level” interfaceS existed in >>>> the world. Clearly QEMU could provide one, two, or many. But, why >>>> do you think QEMU ‘must’ provide them? >>> >>> To serve our users who are not all wanting to be use a management >>> layer. They want to be using a simple binary to spin up adhoc >>> VMs. This is the reason why we've kept most of the short option >>> CLI args in the existing QEMU binaries, despite having more >>> comprehensive low level replacement args. >> >> So - there are >> a) uses today that use the CLI as it exists. >> b) users who might prefer a better interface if that was made available - >> but, again, that doesn’t require QEMU itself to do anything. If we provide a >> low-level API, and somebody else (you for instance) provides a ’nice’ >> ‘friendly’ CLI or config file reader - those users would be happy. >> >> I still dont see why QEMU itself needs to provide this ‘high level’ thing. > > The QEMU project has provided this high level CLI itself historically. > In previous discussions about dropping the simplified options, leaving > only the QAPI based options, that idea has always been rejected by a > non-trivial number of QEMU maintainers who consider it a core part of > our deliverable as a project. > >> >> I think we all agree (correct me if I’m wrong) : >> * We all want a low level interface >> * We all want the current CLI to be supported (at least for now, though it >> could change in time) >> * We all want the CLI to be based on the low level interface >> >> I’m just asking why we ALSO want to support “yet another high level >> interface”…. > > You're arguing for a significant change in the scope of what QEMU > delivers to its users, punting a bunch of functionality to be > someone else's problem. > > >>> If we just declare we're not going to provide this simple binary >>> any more, then we're just casting these users adrift. This in >> >> “Any more” - Are you talking about the existing CLI users? > > Yes. > >>> effect means they'll just carry on existing the historical QEMU >>> binaries and we'll never be able to eliminate them, so we'll be >>> maintaining two things forever. >> >> A CLI and the low level interface? - Yes? Can we remove the CLI >> and only support the low-level interface ? But here you seem to >> be arguing against yourself, so I guess I misunderstood. > > The current qemu-system-$TARGET emulators have a variety of > CLI args, some low level QAPI driven, and some higher level > simplified args. Mgmt app consumers tend to use the former, > while our humans userbase tends to use the latter. I'm > saying we need to carry on serving both userbases, unless > we get the QEMU maintainers in general to agree to a pretty > significant change in what the project delivers. Based on > previous discussions, I'm doubtful we'll get agreement to > do that. > > So if we're going to successfully introduce replacement > for qemu-system-$TARGET, we need to cater for both userbases, > albeit we can do so with separate binaries, rather than trying > to cram low level and high level into the same. > > > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| >