krb5 thread support and excess support libraries --seekingopinions, options

[Douglas E. Engert]

Will these routines be useful for other applications that need to 
be thread safe, or are they Kerberos internal only? If com_err
needs to use them it sounds like they could be independent of 
Kerberos.  

Ken Raeburn wrote:
> 
> As previously mentioned, the support for thread-specific data is going
> to require some additional code, too much to hide in big macros or
> inline functions.  It's also going to require some global storage.
> 
> Sam and Tom and I talked about where to put this code.  So far, we
> don't have any good solutions.  If anyone can suggest a point out pros
> and cons we've overlooked, or other options we didn't consider, we'd
> be grateful.
> 
> None of the existing libraries is really ideal to put one copy of the
> code, to be used by other libraries.  It's needed by the com_err
> library, and we can't make libcom_err depend on one of the
> higher-level libraries, that also depends on libcom_err.  The com_err
> library also isn't an especially appropriate place for it, in terms of
> functionality.  And we're supporting the use of a native libcom_err,
> so we can't rely on ours being the one to be built.
> 
> If we simply duplicate the code in each library that needs it, we're
> going to get name conflicts.  Changing the symbol names for each
> library means recompiling the code multiple times with different
> options, or different tweaks to the source, or something like that.
> Sam was pretty strongly opposed to solution, though I'm inclined to
> think it's the least ugly of the options we've come up with.
> 
> So the path we're trying right now is to add yet another library, for
> support code "below" the other libraries.  (Kind of like Heimdal's
> libroken, I think.)  Any other library or program which uses this
> stuff gets linked against it.  Since the com_err library is one such,
> and since we still support static linking, that means pretty much
> every program we build uses it indirectly, and any applications based
> on our code.  If anyone isn't using the krb5-config script now, this
> change is likely to hurt them, if we keep it.
> 
> It gets tempting to use something like GNU libtool, but last time we
> looked at it, it was much slower than putting the relevant compile and
> link commands directly in the makefile, and it didn't support some
> things we're doing now, like shared library export lists and
> initialization and termination functions.
> 
> Since we're looking at a new support library, we also talked about
> moving some other stuff into it, namely the fake getaddrinfo support
> for platforms that don't have it, the getaddrinfo caching support for
> misconfigured platforms, and the code for extracting all of the local
> network interfaces' addresses.
> 
> I've just tried creating the support library and putting the TSD and
> local-address code into it, and it wound up being more painful than
> we'd thought.  As indicated above, every program's link command needs
> updating, for either static or dynamic linking.  On Solaris, running a
> com_err test program now loads the socket library.  And it doesn't
> help that the local-address code included headers which can't be
> generated until after the com_err package is built, which can't happen
> until the support library is built; I can probably work around that.
> 
> So, now I'm looking at moving the local-address code into libkrb5, and
> making the one other use of it, the KDC, use krb5int_accessor to get
> at the function it wants.  (We may want to make kadmind use it too, in
> the passwd server support.)
> 
> The fake getaddrinfo/getnameinfo code is a little more tricky.  It's
> used by libkrb5, libkrb4, libpty, the KDC, telnet, telnetd, and the
> r-commands.  If it goes into the low-level support library, the
> resolver library at least then gets pulled in to everything we build.
> There's already another support library for application-level code,
> lib/apputils, for routines like daemon().  I'm inclined to move the
> getaddrinfo/getnameinfo code into libkrb5, export it with
> krb5int_accessor like the local-address code, and to keep the
> application code relatively clean, let them use a very stripped-down
> fake-addrinfo.h and wrapper functions in lib/apputils so they don't
> have to pull in all of k5-int.h.  (So aside from including
> fake-addrinfo.h, they'd pretend that getaddrinfo and friends always
> exists and works, which is the way we're doing it now.  Nice and easy
> to undo, if the applications get split off into a separate package.)
> Unless any better suggestions come along....
> 
> That brings the low-level support library back to just having the
> thread-specific data support for now, a fairly tiny slice of code to
> warrant a new library of its own.
> 
> Ken
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

-- 

 Douglas E. Engert  <DEEngert at anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444