com_err reunification

[Theodore Tso]

On Sun, Jul 09, 2006 at 02:01:59PM -0700, Russ Allbery wrote:
> Ken Raeburn <raeburn at MIT.EDU> writes:
> 
> > True.  Though for issues like thread safety, I think it's important to
> > consider *not* including the inherently-unsafe interfaces, specifically
> > the direct manipulation of the global linked list in the generated .c
> > files, so thread safety is *possible* through the support library.
> 
> Yes, if we could find a way to do the transition, I think we'd want to
> transition to a library that supports only the safe interfaces and can't
> do the wrong thing.  I just don't know how to do the transition.

The whole point of the version bump would be to remove the unsafe
interfaces.  We can always add new interfaces, but removing interfaces
is by definition an incompatible ABI change.

What makes things worse though is that we have four different
objects/entites for which we need to manage compatibility: the
application, the com_err library, the library providing error tables,
and the compile_et program.  Compile_et is the one which gets tricky
because some client programs either provide their own built-in
compile_et program, or use pre-built XXX_err.c and .h files which may
be using the unsafe interfaces.

The goal would be to make it blindly obvious at compile time that
people need to upgrade.  So let us assume that the com_err.h and
library link files are always a matched set (if you have the v2
com_err.h, you also have the v2 link libraries).  

1) To catch the case of an application using its own built-in
compile_et, or pre-built *_err.[ch] files, the V2 com_err.h should
#define _et_list to something which causes a compilation error.  So if
someone tries to compile V1 gtenerated _err.[ch] file in a com_err V2
development environment, it won't work.

2) The V2 com_err.h file should define some symbol (say,
COMERR_VERS=2), and compile_et should generate .c and .h files which
#include <et/com_err.h> and then check for that symbol.  If it doesn't
exist, they should force a compilation error using #error.  

3) The shared version number bump and the elimination of the unsafe
interfaces (and perhaps some of the other duplicative interfaces, if
we believe this is a good time to force all clients to a common,
slimmed down set of API's) should take care of the rest.

I think this should work, although since we are removing unsafe
interfaces, we *will* break some old code until they can be changed to
use the newer safer interfaces.

> I think the OpenAFS com_err adds locking in yet another different way, and
> I'm not sure if something that just relies on pthreads would be sufficient
> in OpenAFS (there's all that LWP stuff still in there, but I don't know
> how it influences this problem).

Well, that would depend on whether or not LWP and pthreads can coexist
in the same address space, I would think.

						- Ted