[stgt] [PATCH] Make backends loadable modules

[ronnie sahlberg]

Ok
Let me create a patch over the next few days.



On Wed, Sep 18, 2013 at 2:46 AM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> Again, so sorry.
>
> On Wed, 28 Aug 2013 09:53:03 -0700
> Andy Grover <agrover at redhat.com> wrote:
>
>> On 08/28/2013 02:34 AM, Boaz Harrosh wrote:
>> > On 08/28/2013 07:59 AM, ronnie sahlberg wrote:
>> >> On Tue, Aug 27, 2013 at 3:56 PM, Andy Grover <agrover at redhat.com> wrote:
>> >>> I think you may be able to avoid making bs.c into a shared library if you
>> >>> link tgtd with the -E linker option.
>> >
>> > Personally I prefer the .so option:
>> >
>> > For one I hate any double dependency, and specially an executable dependency.
>> > This is bad code design and a call for tons of problems. It is called the
>> > libraries hell. Each module should be self contained or only depend downwards
>> > on lower stack. library rules are exactly like package rules only depend
>> > downwards, and the complex dependency should be a tree never a graph ...
>> >
>> > Second with the bs.c as library it is clear and protected what are the API's
>> > the backends are to depend on and import, No crazy unexpected stuff from
>> > a loaded plugin.
>> >
>> > Please keep the second version as you sent it it is a much better style
>> > than the -E hack.
>>
>> You only get library hell when there are binary modules that expect to
>> run across different versions of the executable. I don't think that's
>> what we're talking about here. My initial request was to make it
>> possible for users to avoid installing dependencies for parts of tgt
>> they won't be using. That just requires tgtd and bs_rbd.so be separate
>> binaries, and tgtd work in the the absence of bs_rbd. Both binaries
>> would always still be generated from the same source version.
>>
>> So for me, linking tgtd with -E seems like the simplest solution to
>> reach that modest goal, but I'm fine with whatever Ronnie and Tomo do,
>> as long as it does the basic thing :-)
>
> Agreed, I prefer the approach, which looks like the simplest way to
> fix the problem we want to solve. I have no plan to support the
> complicated stuff like the different versions of the combination. I
> also don't think that others want to do so.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html