<div dir="ltr">The point of the standard API for different drivers is to have the same name for functionality. Otherwise a change of providers would require source code changes or some other tricks. The use of inlines of course means that the code needs to refer to symbols that are particular for that specific provider. Linking to another providers .o file should not succeed.<div>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 6, 2013 at 6:27 PM, Jason Gunthorpe <span dir="ltr"><<a href="mailto:jgunthorpe@obsidianresearch.com" target="_blank">jgunthorpe@obsidianresearch.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Dec 06, 2013 at 04:10:08PM -0800, Christoph Lameter wrote:<br>
<br>
> Oh with dlopen you can load multiple implementation with the same function<br>
> names. The multiplex layer can build function vectors for these and provide<br>
> some sort of selection function for devices. Then we are back to the existing<br>
> overhead. The multiplex layer can supply many of the same functions that the<br>
> provider layer also offers and then route to the correct driver that it may<br>
> dynamically load.<br>
<br>
</div>I've never messed enough with RTLD_LOCAL to know if that would work<br>
properly in all cases.. With that scheme all providers would define<br>
the same symbols..<br>
<br>
Though I think I'd prefer to have provider-specific symbol names so at<br>
least you get dynamic linker failures if things are setup wrong.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jason<br>
</font></span></blockquote></div><br></div>