[Sheepdog] Sheepdog client library

[MORITA Kazutaka]

Chris Webb wrote:
> In the spirit of merging dog and sheep, do you think it would also be worth
> pulling the sheepdog client code into the sheepdog tree instead of putting
> it directly into qemu/block/sheepdog.c?
> 
> If sd_open, sd_aio_readv, &c were in a small libsheepdog rather than being
> part of qemu, other programs than qemu could easily link to them as well,
> such as a simple 'block read/write' tool for testing and perhaps completely
> different applications which could make use of a distributed drive image
> store. The block/sheepdog.c distributed with qemu would then just be a
> little shim linking against libsheepdog and behaving exactly as present.

If libsheepdog is used for other applications, it is great.
But the applications may be few in number because of sheepdog restrictions
on data accessing; if vdi is locked, any other client cannot even read the vdi.
About testing purpose, I think qemu-io is enough useful. 

> This might make future sheepdog development a bit easier administratively in
> the long term too. If the client and server code are developed together in
> the same independent project, changes with client and server can be
> committed together, whereas if the client is in qemu separate from sheepdog,
> a particular version of the client ends up tied to a particular version of
> qemu.
> 
> What do you think?

I wonder whether sheepdog would be more easier to administrate. 
Developers will relink libsheepdog to qemu-* every time
libsheepdog is recompiled, and users need to select proper libsheepdog
if qemu block I/O code is changed.

Anyway, I generally agree with you.
I'll think more about this issue. 

Regards,

MORITA Kazutaka