qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/3] QMP: Introduce Human Monitor passthrough co


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH 2/3] QMP: Introduce Human Monitor passthrough command
Date: Thu, 11 Nov 2010 15:55:55 +0000
User-agent: Mutt/1.4.1i

On Thu, Nov 11, 2010 at 04:47:41PM +0100, Markus Armbruster wrote:
> Luiz Capitulino <address@hidden> writes:
> 
> > On Wed, 10 Nov 2010 14:20:12 +0100
> > Markus Armbruster <address@hidden> wrote:
> >
> >> Luiz Capitulino <address@hidden> writes:
> [...]
> >> > diff --git a/qmp-commands.hx b/qmp-commands.hx
> >> > index 793cf1c..b344096 100644
> >> > --- a/qmp-commands.hx
> >> > +++ b/qmp-commands.hx
> >> > @@ -761,6 +761,51 @@ Example:
> >> >  
> >> >  Note: This command must be issued before issuing any other command.
> >> >  
> >> > +EQMP
> >> > +
> >> > +    {
> >> > +        .name       = "hmp_passthrough",
> >> > +        .args_type  = "command-line:s,cpu-index:i?",
> >> > +        .params     = "",
> >> > +        .help       = "",
> >> > +        .user_print = monitor_user_noop,
> >> > +        .mhandler.cmd_new = do_hmp_passthrough,
> >> > +    },
> >> > +
> >> > +SQMP
> >> > +hmp_passthrough
> >> > +---------------
> >> > +
> >> > +Execute a Human Monitor command.
> >> > +
> >> > +Arguments: 
> >> > +
> >> > +- command-line: the command name and its arguments, just like the
> >> > +                Human Monitor's shell (json-string)
> >> > +- cpu-index: select the CPU number to be used by commands which access 
> >> > CPU
> >> > +             data, like 'info registers'. The Monitor selects CPU 0 if 
> >> > this
> >> > +             argument is not provided (json-int, optional)
> >> > +
> >> > +Example:
> >> > +
> >> > +-> { "execute": "hmp_passthrough", "arguments": { "command-line": "info 
> >> > kvm" } }
> >> > +<- { "return": "kvm support: enabled\r\n" }
> >> > +
> >> > +Notes:
> >> > +
> >> > +(1) The Human Monitor is NOT an stable interface, this means that 
> >> > command
> >> > +    names, arguments and responses can change or be removed at ANY time.
> >> > +    Applications that rely on long term stability guarantees should NOT
> >> > +    use this command
> >> > +
> >> > +(2) Limitations:
> >> > +
> >> > +    o This command is stateless, this means that commands that depend
> >> > +      on state information (such as getfd) might not work
> >> > +
> >> > +    o Commands that prompt the user for data (eg. 'cont' when the block
> >> > +      device is encrypted) don't currently work
> >> > +
> >> >  3. Query Commands
> >> >  =================
> >> 
> >> In the real human monitor, cpu-index is state (Monitor member mon_cpu).
> >> For pass through, you shift that state into the client (argument
> >> cpu-index).  Is there any other state that could need shifting?  You
> >> mention getfd.
> >
> > Surprisingly or not, this is a very important question for QMP itself.
> >
> > Anthony has said that we should make it stateless, and I do think this
> > is good because it seems to simplify things considerably.
> >
> > However, I haven't thought about how to make things like getfd stateless.
> 
> Hmm, that sounds like we should investigate the getfd problem sooner
> rather than later.

The SCM_RIGHTS code allows you to send/receive multiple file handles in a 
single sendmsg/recvmsg  call. So why don't we just allow sending of the
file handles with the monitor command that actually needs them, instead of
ahead of time using send_fd. This simplifies life for the client because
they also don't have to worry about cleanup using close_fd if the command
using the FD fails.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]