> On Feb 25, 2014, at 11:01 PM, NeilBrown <neilb@xxxxxxx> wrote: > >> On Tue, 25 Feb 2014 22:06:58 -0800 Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> >> >> >>> On Feb 25, 2014, at 9:16 PM, NeilBrown <neilb@xxxxxxx> wrote: >>> >>> >>> See $SUBJ >>> >>> Shared libraries are usually versioned so you can release a new version with >>> an incompatible API and gradually transition to it. >>> >>> A rpc.mountd dlopens libnfsjunct.so with no version it is effectively >>> prohibited from ever changing the API in an incompatible way. >> >> There is an API version field that mountd can examine before using the plug-in. .so symlinks to whichever library version is the blessed one. > > What exactly does "blessed one" mean... It means the one the local administrator chooses to use. The only reason to have more than one plug-in version installed is when testing an upgrade. > > Maybe the question I want to ask is: > Is libnfsjunct.so something that only rpc.mountd would ever use and it could > not possibly make any sense for anything else to ever use it? There is a public header in /usr/include that contains the API definition. In the future the plug-in might also be able to perform administrative operations on junctions, and other applications could invoke this functionality via the plug-in. I don't think it's applicability is narrow, even though mountd is its only user today. > > If so, then we probably don't want to install the .so.0 or .so.0.0.0 files > and maybe should give libnfsjunct.so a different suffix because it is not > "shared" in any sense (I wanted to suggest ".lo" for loadable object, but I > think that is already used). > > If not, then you could conceivably have two tool installed which use > different version, so it doesn't make sense for either to be "blessed". > The bare ".so" name would be "the version that should be used when building > anything from source". I don't understand this last bit. The plug-in can get bug fixes and new features and mountd does not need to be rebuilt from source to use them. > > Does the question have a simple answer? I'm afraid I don't yet understand the problem you are trying to solve. > > Thanks, > NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
