[stgt] [PATCH] Make backends loadable modules

[Andy Grover]

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 :-)

 > Also in porting to other platforms the executable exporting symbols is
 > not available on all platforms.

Do you have more info? 'ld' manpage didn't mention any platform issues.

Regards -- Andy

--
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