[stgt] [PATCH] Make backends loadable modules

FUJITA Tomonori fujita.tomonori at lab.ntt.co.jp
Wed Sep 18 11:46:55 CEST 2013

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

More information about the stgt mailing list