[OpenAFS-devel] Re: [OpenAFS] jafs et al

[Marcus Watts]

Russ Allbery <rra@stanford.edu> writes:
> Jeffrey Hutzelman <jhutz@cmu.edu> writes:
> 
> > What Solaris symbol versioning does is let you define multiple interface
> > versions, and indicate which symbols belong to which interface
> > versions. This allows the linker to generate proper version
> > dependencies, and the runtime linker to verify that you have a new
> > enough library, both without being overly restrictive about version
> > matching.  However, you cannot have multiple versions of a symbol in the
> > same library, or in the same process. If something changes in a
> > backwards-incompatible way, its name must also change.
> 
> Oh, okay, so it's about adding new ABIs and doing proper runtime detection
> if the library is new enough for the binary without being too restrictive.
> That's useful, but not as interesting.

What I would have said is that solaris symbol versioning provides
better error messages with a clue as to what is "supported".  OpenAFS
uses a "degenerate" form of this versioning - basically what isn't
supported isn't exported.  This degenerate form happens to look a lot
like the "export" facility of aix & ms windows, so this actually
leverages interplatform commonality.  If you were looking to support
"what everybody does" -- this is it, this is the state of the art.

The gnu-specific extensions to solaris versioning including .symver
allows incompatible abi changes to "one routine" in one binary.  So the
same shared library can support both the "old" call and the "new" call
using the "same" name.  The shared library has to have a fair amount of
gnu-specific local smarts to make this work.

The solaris equivalent to this is a "major version" bump - using soname
to select a completely different shared library (same name, but
different major number).  Solaris & darwin both provide a form of
"two-level" name spaces, so different shared objects can access
different libraries yet avoid name space collisions.  So, with this
scheme in solaris, the "old" library is the old library - it doesn't
know about the new library at all.  MacOS X has some sort of versioned
framework thing going on, which sort of does the same thing but
involves a more complicated filesystem layout unique to Apple and
completely incompatible with FHS.

I don't think any of this is going to let you do what you want with AFS::*
in any sort of portable fashion.  The closest you are going to get
is to segment AFS::* into 2-4 pieces, have each piece have its own
shared object, and have those different shared objects use what they need.
So you might have something like:
	p5-afs-ka-pthread.so
		kerberos 4 specific administrative stuff,
		that's not part of authent.
		part of AFS::KAS
		(which you can then deprecate...)
	p5-afs-pthread.so
		everything that's available via authent.
		AFS::PTS AFS::CM etc.
		part of AFS::KAS?
		AFS::KTC_EKEY AFS::KTC_PRINCIPAL AFS::KTC_TOKEN
		whatever of AFS::VLDB AFS::FS etc can be trivially
		made thread safe.
	p5-afs-lwp.so
		everything that only works via lwp.
		AFS::VOS
		whatever of AFS::VLDB AFS::FS etc can't be trivially
		made thread safe.
	p5-afs-utils.so
		whatever parts of AFS do not care about threads
		and aren't in afsauthent or whatever.
		afsutil?
and use of dlopen in C or autoloader in perl logic to
load these as needed.  This will allow you to use the "two-level"
name space support, on platforms that support it (probably most
today).  For platforms that don't support this, there is nothing
portable or simple you can do to support lwp and pthread code in
one binary.  You still have a responsibility, in user code (ie, in
your thread-aware perl application) not to call lwp code from more
than one pthread at the "same time".  Otherwise, bad things will happen
when one pthread tries to schedule the other pthread's lwp threads.

				-Marcus