Ok Let me create a patch over the next few days. On Wed, Sep 18, 2013 at 2:46 AM, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > Again, so sorry. > > On Wed, 28 Aug 2013 09:53:03 -0700 > Andy Grover <agrover@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
