You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2006/02/07 00:41:45 UTC
[PATCH] Multiple RA layer initialization
In my work with ra_serf, I've come across the problem that we really
can't have multiple RA layers declare for the same scheme gracefully.
The current RA implementation will treat a NULL init value to be 'load
this as a DSO' - if the DSO load fails, then it will never try another
RA layer. load_ra_module returns a fatal error - on my machine it
figures out the library isn't there only in apr_dso_sym not in
apr_dso_load.
I'm not quite sure if it should be even trying the DSO load at all or
should it try other ra_libraries instead?
My first thought is that it shouldn't try at all. So, I'm using this
patch which moves the conditionals to encompass the entire scheme
definition - this way, it'll never 'see' ra_dav, but will try to load
ra_serf.
Thoughts? -- justin
* subversion/libsvn_ra/ra_loader.c
(ra_libraries): Make #ifdef around entire scheme rather than just
the init function
Re: [PATCH] Multiple RA layer initialization
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 2/6/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> In my work with ra_serf, I've come across the problem that we really
> can't have multiple RA layers declare for the same scheme gracefully.
> The current RA implementation will treat a NULL init value to be 'load
> this as a DSO' - if the DSO load fails, then it will never try another
> RA layer. load_ra_module returns a fatal error - on my machine it
> figures out the library isn't there only in apr_dso_sym not in
> apr_dso_load.
>
> I'm not quite sure if it should be even trying the DSO load at all or
> should it try other ra_libraries instead?
>
> My first thought is that it shouldn't try at all. So, I'm using this
> patch which moves the conditionals to encompass the entire scheme
> definition - this way, it'll never 'see' ra_dav, but will try to load
> ra_serf.
It seems kind of odd that it tries to load them if they weren't
compiled at first, but then again I'm not really clear how the people
who build dso ra layers actually make all that work with the build
system, so perhaps that makes more sense from that perspective.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Multiple RA layer initialization
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Tue, 7 Feb 2006, Greg Stein wrote:
> On Tue, Feb 07, 2006 at 11:50:06AM -0800, Justin Erenkrantz wrote:
> > On 2/7/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> > > My point is that we always know what ra libraries we built, even if we use
> > > --enable-dso, but anyway...
> >
> > Not really - people could build ra_serf or ra_dav independently of the
> > main binary.
>
> Or ship a subset. Or a third-party access mechanism completely
> independent of Subversion. These were a couple of the design points
> behind the idea of a dynamically loadable RA module.
>
We don't support third-party modules, since the module API is not public.
It can change between releases.
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Multiple RA layer initialization
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 07, 2006 at 11:50:06AM -0800, Justin Erenkrantz wrote:
> On 2/7/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> > My point is that we always know what ra libraries we built, even if we use
> > --enable-dso, but anyway...
>
> Not really - people could build ra_serf or ra_dav independently of the
> main binary.
Or ship a subset. Or a third-party access mechanism completely
independent of Subversion. These were a couple of the design points
behind the idea of a dynamically loadable RA module.
(tho never went as far as true discovery/config, so there is still
some updating of the table that has to happen and be compiled in...)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Multiple RA layer initialization
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 2/7/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> My point is that we always know what ra libraries we built, even if we use
> --enable-dso, but anyway...
Not really - people could build ra_serf or ra_dav independently of the
main binary.
> > How about the following patch instead? -- justin
> >
> Looks good. If it works with --enable-dso, +1. (I'm also fine with
> looking for both libs; it is just one extra dlopen and we have version
> checks to detect mismatches).
It does, AFAICT. If no one complains, I'll commit later today. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Multiple RA layer initialization
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Tue, 7 Feb 2006, Justin Erenkrantz wrote:
> On 2/7/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> > Hmmm, I don't think this will work with --enable-dso because the LINKS
> > macros won't be defined in that case. Can't you have extra #defines for
> > the two libraries that "conflict"? We're only allowing one to be built at
> > a time, right?
>
> The problem here is to try to allow DSOs while not doing Stupid Things(TM).
>
My point is that we always know what ra libraries we built, even if we use
--enable-dso, but anyway...
> How about the following patch instead? -- justin
>
Looks good. If it works with --enable-dso, +1. (I'm also fine with
looking for both libs; it is just one extra dlopen and we have version
checks to detect mismatches).
Best,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Multiple RA layer initialization
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 2/7/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> Hmmm, I don't think this will work with --enable-dso because the LINKS
> macros won't be defined in that case. Can't you have extra #defines for
> the two libraries that "conflict"? We're only allowing one to be built at
> a time, right?
The problem here is to try to allow DSOs while not doing Stupid Things(TM).
I'm fine with it looking for 'ra_dav' and 'ra_serf' at the same time -
but the problem here is that because of our scheme system if it tried
to look ra_dav and fails, it'll never work.
How about the following patch instead? -- justin
Re: [PATCH] Multiple RA layer initialization
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Mon, 6 Feb 2006, Justin Erenkrantz wrote:
> In my work with ra_serf, I've come across the problem that we really
> can't have multiple RA layers declare for the same scheme gracefully.
> The current RA implementation will treat a NULL init value to be 'load
> this as a DSO' - if the DSO load fails, then it will never try another
> RA layer. load_ra_module returns a fatal error - on my machine it
> figures out the library isn't there only in apr_dso_sym not in
> apr_dso_load.
>
> I'm not quite sure if it should be even trying the DSO load at all or
> should it try other ra_libraries instead?
>
> My first thought is that it shouldn't try at all. So, I'm using this
> patch which moves the conditionals to encompass the entire scheme
> definition - this way, it'll never 'see' ra_dav, but will try to load
> ra_serf.
>
Hmmm, I don't think this will work with --enable-dso because the LINKS
macros won't be defined in that case. Can't you have extra #defines for
the two libraries that "conflict"? We're only allowing one to be built at
a time, right?
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org