[1604] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: util/makeshlib

daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Fri Aug 16 18:19:21 1996

Date: Fri, 16 Aug 1996 18:19:10 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Tom Yu <tlyu@MIT.EDU>
Cc: epeisach@MIT.EDU, tlyu@MIT.EDU, krbcore@MIT.EDU
In-Reply-To: Tom Yu's message of Thu, 15 Aug 1996 23:44:10 -0400,
	<199608160344.XAA19535@dragons-lair.MIT.EDU>

   Date: Thu, 15 Aug 1996 23:44:10 -0400
   From: Tom Yu <tlyu@MIT.EDU>

       Ezra> a) A better solution - in the dispatch table put a
       Ezra> NULL.... If you will note, the macros which use dbm_error
       Ezra> and dbm_clearerr are never used!!

       Ezra> b) Even better solution - remove elements from the dispatch
       Ezra> tables which are never used.

   I've thought of these... and they both seem reasonable.  Then again
   since we're already abstracting things away via the kdb dispatch
   table, why not use the native db API, and only use the ndbm API if
   someone wants to compile with ndbm for some unknown reason?

Throwing away the kdb dispatch is the ultimate right answer.  I wasn't
planning on doing this before Beta 7, but if it's causing us problems,
perhaps we should just do it.  The changes are localized in one file,
after all, and the changes will either work or not, so it will be easy
to test.

If for some reason we need to use ndbm, the right way to do this is to
hack it into the *db*'s internal dispatch table, and simply redirect
berk-db to use ndbm instead of its internal hash library.  At this
point, I suspect the only reason why we'd need to do this is in case we
find Yet More Horrible Hash Bugs that neither Marc nor Margo can fix in
a hurry.

The current situation where the kdb dispatch table is used to call db,
which then uses a dispatch table to call the hash library is a bit
silly.  :-)

							- Ted

home help back first fref pref prev next nref lref last post