[Mono-dev] [PATCH] Make mono_dl_register_library into a fallback

[Paolo Molaro]

On 07/02/10 Michael Hutchinson wrote:
> > This interface is not suitable as a fallback mechanism, it would be too
> > cumbersome to use and it's probably not ideal even for its intended
> > purpose. What about a callback registration system instead?
> 
> The intended purpose, AFAIK, is to expose statically linked libraries
> to P/Invoke. That's what I'm using it for, and it's very
> straightforward to use this way. I have a trivial C# tool that
> reflects over the library with the P/Invokes and dumps the mappings to
> source files.

The interface was just a quick hack from Miguel, in fact is has never
been exposed as public API as you found out (it was only possible to use
it in a custom mono build for consoles).
If you have a tool generating the table now, changing it to generate
the function needed by the new interface should be trivial, anyway.

> My patch isn't intended to provide a generic dynamic linker fallback.

But it does change the code to fallback and you want to publish the API,
so then we're stuck with an unsuitable API for a new feature.

> It's meant to provide an easy way to P/Invoke statically linked
> libraries for all embedders, not just those on platforms without
> dynamic linkers.

If you have a working dynamic linker using DllImport ("__Internal")
is the way to go.

> That's certainly more flexible, but I'm not convinced it's necessary
> at this time without concrete use cases. If we're going to include the

If you don't have concrete cases, why are you expanding the
functionality of the quick and dirty (and non-public) API?

> old interface anyway - else we make embedders responsible for
> reimplementing its functionality - then why not go this path for now,
> and reimplement it on top of the callbacks later?

Because it means exposing an API and attaching to it functionality it's not
suited for.

> The tricks you mention could be much more useful if callbacks could
> intercept lookups for individual symbols, rather than acting as a
> fallback for handling whole libraries. But this would require much
> more substantial changes to the dynamic linker code.

A separate API entry point could be added for that.
To recap:
*) that API was never public.
*) I'm not comfortable with publishing that API and supporting it
with the fallback functionality.
*) if we need a fallback mechanism something like my proposed
interface is much better and I think is suitable for publishing
(maybe with an additional flags value to give a priority vs the
existing lookups).

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better