On Tue, 4 Jun 2013 14:49:55 +0200
Kevin Wolf <kw...@redhat.com> wrote:
> Am 04.06.2013 um 14:40 hat Luiz Capitulino geschrieben:
> > On Tue, 4 Jun 2013 12:08:23 +0200
> > Kevin Wolf <kw...@redhat.com> wrote:
> >
> > > Am 29.05.2013 um 19:51 hat Luiz Capitulino geschrieben:
> > > > On Wed, 29 May 2013 10:13:42 +0200
> > > > Kevin Wolf <kw...@redhat.com> wrote:
> > > >
> > > > > Am 28.05.2013 um 18:07 hat Eric Blake geschrieben:
> > > > > > On 05/28/2013 09:27 AM, Kevin Wolf wrote:
> > > > > > > The QMP version is flagged with a __org.qemu.debug- prefix in
> > > > > > > order to
> > > > > > > reinforce the statement that qemu-io is for testing and debugging
> > > > > > > only,
> > > > > > > with no API guarantees.
> > > > > >
> > > > > > Correct use of naming conventions.
> > > > > >
> > > > > > Hmm, I wonder if the recent addition of an 'abort' action to
> > > > > > 'transaction' should be renamed __org.qemu.debug-abort, to make it
> > > > > > obvious that it is another case of a QMP command useful mainly for
> > > > > > testing, and not real-life use.
> > > > >
> > > > > Makes sense to me.
> > > > >
> > > > > But first I'd like to get Luiz's ack for this, because I think I'm the
> > > > > first one to use an __org.qemu prefix, and I'm the first one trying to
> > > > > introduce a QMP command without API stability.
> > > >
> > > > I think that should be fine. However, it's not a perfect match for QMP
> > > > as you don't expect mngt to use it anytime soon and that the command's
> > > > syntax is not QMP friendly:
> > > >
> > > > > { "execute": "__org.qemu.debug-qemu-io-command", "arguments":
> > > > > { "device": "ide0-hd0", "command": "write -P 0x12 4M 512k" } }
> > > >
> > > > What about adding a HMP-only command (the good old way) and use it
> > > > through human-monitor-command?
> > > >
> > > > IMO, this matches better your current use-case and the API instability
> > > > of the command.
> > >
> > > Works for me, but wasn't the plan to make HMP purely a wrapper around
> > > QMP? Then adding HMP-only commands would be counterproductive. So I
> > > assumed that QMP is a must. I didn't even know that the code still
> > > allows you to have HMP-only commands. :-)
> >
> > Yes, the long term plan is to have all HMP commands calling QMP
> > counterparts. But the command you're adding doesn't fit QMP's design
> > very well.
>
> It fits the design about as well as human-monitor-command. Both are
> passthrough commands, one to HMP, the other one to qemu-io.
Yes, but human-monitor-command is a stop gap command meant to be an
exception. It's usage should decrease over time. I'd expect the opposite
for qemu-io-command.
> > I suggested adding it as HMP-only for now because it's the simplest
> > thing to do for this very specific case.
> >
> > If more test-only non-QMP-friendly commands appear, then we'll need
> > to think of a more general solution.
>
> What does "for now" mean, and what will the proper long-term solution
> look like?
For now means: until we know what the proper solution should be. I Honestly
don't know what's the best/proper solution here, that's why I suggested
having this in HMP first, so that we don't commit ourselves to anything
prematurely.
> > Now, something has just occurred to me. Why isn't it a good idea having
> > this command as a stable API? Wouldn't it be a good idea to allow
> > out-of-tree test tools like autotest to use it?
>
> Because qemu-io exposes internals of the block layer that we don't want
> to make a stable API.
What kind of internals? In the example you posted I see just a generic
enough write command.
> Autotest can have test cases using this, but
> they'd have to be against a specific qemu version.
>
> > > So you prefer a respin with the QMP part dropped?
> >
> > Yes.
>
> Okay, I'll do that.
>
> Kevin
>
