On Thu, Sep 26, 2013 at 6:59 PM, Dan Mick <dan.mick@xxxxxxxxxxx> 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. regards ronnie sahlberg -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
