qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 06/11] chardev: add file chardev support to char


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH 06/11] chardev: add file chardev support to chardev-add (qmp)
Date: Thu, 10 Jan 2013 10:10:59 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121116 Thunderbird/10.0.11

On 01/09/13 19:12, Eric Blake wrote:
> On 01/07/2013 06:55 AM, Gerd Hoffmann wrote:
>> Add support for file chardevs.  Output file is mandatory, input
>> file is optional.  Both file names and file descriptor passing is
>> supported.
>> 
>> Signed-off-by: Gerd Hoffmann <address@hidden> --- 
>> qapi-schema.json |    9 +++++- qemu-char.c      |   77
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++- 2 files
>> changed, 84 insertions(+), 2 deletions(-)
>> 
>> diff --git a/qapi-schema.json b/qapi-schema.json index
>> e3f0d44..8904d36 100644 --- a/qapi-schema.json +++
>> b/qapi-schema.json @@ -3030,9 +3030,16 @@ # # Since: 1.4 ## +{
>> 'union': 'ChardevFileSource', 'data': { 'path' : 'str', +
>> 'fd'   : 'str' } } + +{ 'type': 'ChardevFile', 'data': { '*in' :
>> 'ChardevFileSource', +                                   'out' :
>> 'ChardevFileSource' } } + { 'type': 'ChardevDummy', 'data': { }
>> }
>> 
>> -{ 'union': 'ChardevBackend', 'data': { 'null' : 'ChardevDummy' }
>> } +{ 'union': 'ChardevBackend', 'data': { 'file' :
>> 'ChardevFile', +                                       'null' :
>> 'ChardevDummy' } }
>> 
>> { 'command': 'chardev-add', 'data': {'id'      : 'str', 'backend'
>> : 'ChardevBackend' } }
> 
> An example in qmp-commands.hx would be helpful; am I correct that
> an example would be:
> 
> -> { "execute" : "chardev-add", "arguments" : { "id" : "foo", 
> "backend" : { "type" : "file", "data" : { "in"  : { "type" : "fd",
> "data" : "namedfd" }, "out" : { "type" : "path", "data" :
> "/path/to/file" } } } } } <- { "return": {} }
> 
> where namedfd was previously given via 'getfd'?

Yes.

> Do we need the complexity of supporting fd passing explicitly?
> 'getfd' is less than ideal compared to 'add-fd', and for 'add-fd',
> we would pass via "path":"/dev/fdset/nnn".  That is, why do we need
> to bend over backwards to support an alternate syntax for fd
> passing in a new command, when we can already use existing commands
> to get fd passing for free?

Oh, didn't know that.  Was just following what SocketAddress does and
what Paolo suggested.  It isn't needed indeed.

cheers,
  Gerd



reply via email to

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