[2245] in Kerberos_V5_Development
Re: Problems with the current com_err routines...
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Wed Feb 19 17:31:52 1997
To: tytso@MIT.EDU
Cc: probe@lehman.com, krbdev@MIT.EDU
From: Ken Raeburn <raeburn@cygnus.com>
Date: 19 Feb 1997 17:25:51 -0500
In-Reply-To: tytso@MIT.EDU's message of Wed, 19 Feb 1997 18:34:39 GMT
tytso@MIT.EDU writes:
> While you did a good job at the current com_err revamp, there
> are a couple of problems with it. The main issue is that the new
> xxx_err.c file is incompatible with older com_err libraries. On the
> Windows side, this is inevitable; however, on the Unix side, we should
> be able to avoid this altogether.
>
> What do we need to do this? First of all, the xxx_err.c
> *shouldn't* call add_error_table(). The initialize_foo_error_table()
> should do what it did before, by manipulating _et_list. The krb5
> library on the Unix side *shouldn't* depend on remove_error_table(),
> since that doesn't exist on the older com_err libraries.
Actually, aside from namespace issues, I think Richard's solution
sounds reasonable. (I haven't looked at the code, just the email
comments.) The _et_list form can never be thread-safe. With most
platforms moving towards having thread support these days, this is a
problem. A change needs to be made, and it can't be 100% compatible.
However, for compatibility, I would suggest keeping the _et_list code
in the library. Then the new library is still compatible with old
error tables (as long as you don't mix old error tables and threads),
and it's only the reverse that fails.
> This should allow Unix krb5 library to continue to work without
> requiring any changes in the com_err library, while allowing the Windows
> side to use the new dynamic registration and de-registration of the
> com_err library.
>
> Comments?
Two words: dlopen, dlclose. If these are used with a library using
com_err and registering error tables, the same problem will arise, on
UNIX. Not very common, but I'll probably be looking into using dlopen
for Kerberos code in the not-too-distant future, actually. (I don't
know about dlclose; that code isn't mine, I'm just looking for the
best way to hook Kerberos in.)
Consistency of the API across platforms would also be nice.
