[sheepdog] [PATCH RFC] add support of sheepdog backing store

[ronnie sahlberg]

On Thu, Sep 26, 2013 at 7:56 PM, Hitoshi Mitake
<mitake.hitoshi at gmail.com> wrote:
> At Thu, 26 Sep 2013 19:29:06 -0700,
> ronnie sahlberg wrote:
>>
>> On Thu, Sep 26, 2013 at 6:59 PM, Dan Mick <dan.mick at inktank.com> wrote:
>> >
>> >>> Some might say this had better to be a dynamic loadable
>> >>> library. Either is fine by me because it doesn't depend on any
>> >>> original C header files.
>> >>
>> >>
>> >> I'm ccing people who would be interested in modular backing
>> >> stores, Ronnie Sahlberg and Andy Grover. I think the sheepdog backing
>> >> store support doesn't have to be a module because it doesn't create
>> >> any new dependencies. Any comments?
>> >
>> >
>> > It seems that you've accomplished this by including structure and constant
>> > definitions (and presumably protocol-marshalling routines) in the tgt source
>> > file itself, which seems to me to be the wrong way to do it, but it does
>> > free you from requiring headers or libraries, so
>> > technically speaking, true.
>> >
>> > I wouldn't write the plugin this way (copying code), but that's me.
>>
>>
>> What Dan said!
>> Since you don't add any new dependencies it shouldn't matter if this
>> is built-in or a module.
>>
>> However, you do this at the cost of having a full blown
>> re-implementation (or it is a copy?) of a sheepdog client in the
>> backing store file.
>> I assume there are client libraries for sheepdog available?
>>
>> So I think from a maintenance viewpoint, it would probably be better
>> if you had the backend just be a thin layer that would call out to and
>> link to the sheepdog client library.
>> I.e. link to a sheedog library instead of reimplementing it in the backend.
>> And in that case then this should be a module.
>
> Thanks for your comment, Dan and Ronnie.
>
> Currently, sheepdog doesn't have its client library. We have a plan to
> implement it. But it will take time.
>
> In addition, the backing store support of sheepdog isn't a simple copy
> (from QEMU). We can't re-implement it by simple copy because current
> sheepdog users, QEMU and tgt, have very different I/O models. e.g.
>  QEMU is a heavy user of coroutine.
>
> After implementing the library, the backing store support of sheepdog
> can be a module. But for now, this patch would be optimal because it
> doesn't increase the cost of tgt maintenance (the patch simply adds a
> single file).
>

Thanks for the explanation.
So if there is no sheepdog library at this stage then I guess there is
no alternative to having a full reimplementation.
In that case it should not matter much whether it is built in or a module.