On 05/24/2010 02:07 PM, Christian Brunner wrote:
> 2010/5/24 MORITA Kazutaka<morita.kazutaka@lab.ntt.co.jp>:
>
>    
>>> However, I don't think nbd would be a good protocol.  My preference
>>> would be for a plugin API, or for a new local protocol that uses
>>> splice() to avoid copies.
>>>
>>>        
>> Both would be okay for Sheepdog.  I want to take a suitable approach
>> for qemu.
>>      
> I think both should be possible:
>
> - Using splice() we would need a daemon that is listening on a control
> socket for
>    requests from qemu-processes or admin commands. When a qemu-process
>    wants to open an image it could call open_image("protocol:imagename") on the
>    controll socket and the daemon has to create a pipe to which the
> image is mapped.
>    (What I'm unsure about, are the security implications. Do we need some kind of
>    authentication for the sockets? What about sVirt?
>    

This is a fairly old patch that I dug out of a backup.  It uses the 9p 
protocol and does proper support for AIO.

At one point in time, I actually implemented splice() support but it 
didn't result in a significant improvement in benchmarks.

> - Building a plugin API seems a bit simpler to me, although I'm to
> sure if I'd get the
>    idea correctly:
>    The block layer has already some kind of api (.bdrv_file_open, .bdrv_read). We
>    could simply compile the block-drivers as shared objects and create a method
>    for loading the necessary modules at runtime.
>    

That approach would be a recipe for disaster.   We would have to 
introduce a new, reduced functionality block API that was supported for 
plugins.  Otherwise, the only way a plugin could keep up with our API 
changes would be if it was in tree which defeats the purpose of having 
plugins.

Regards,

Anthony Liguori

> Are you planing to use this for all block drivers?
>
> Regards,
> Christian
>