tdb_chainlock() in tdb1, tdb2 and tdb_compat ?

[Jeremy Allison]

On Fri, Apr 13, 2012 at 08:07:50AM +0200, Volker Lendecke wrote:
> On Thu, Apr 12, 2012 at 08:24:01PM -0400, simo wrote:
> > On Thu, 2012-04-12 at 23:25 +0200, Volker Lendecke wrote: 
> > > On Thu, Apr 12, 2012 at 01:55:59PM -0700, Jeremy Allison wrote:
> > > > On Thu, Apr 12, 2012 at 04:58:30PM +0200, Volker Lendecke wrote:
> > > > > So hypothetical callers checking
> > > > > 
> > > > > if (tdb_chainlock(...) == -1) {
> > > > > 	/* error path */
> > > > > }
> > > > > 
> > > > > silently would become wrong.
> > > > 
> > > > Ouch. This is a *BIG* API problem (IMHO). Any tdb_compat()
> > > > layer has to provide *exact* tdb1 semantics or we're setting
> > > > ourselves up for a world of pain with different semantics
> > > > called from code that doesn't expect it.
> > > 
> > > One problem here is that the tdb_compat layer if I
> > > understand it correctly (which is far from certain) was
> > > designed to make samba on tdb2 just barely compile. For
> > > example it has a tdb_fetch replacement which for the better
> > > has a completely different prototype which the compiler
> > > would not accept. However, we end up with a tdb_fetch symbol
> > > in libraries, static objects or somewhere else with two
> > > completely different meanings. This alone will lead to all
> > > sorts of problems, at least it will require a lot of care
> > > and coordination not to cause hickups.
> > 
> > I think tdb2 is different enough we should really not mix tdb with tdb2.
> > It would be better to rename all tdb2 apis to not clash with tdb1 and
> > slowly convert callers while we keep both dependencies.
> > Once all tdb1 callers are gone we have only tdb2 left to maintain.
> 
> +1.

+1 from me also. Trying to mix the two is a receipe for disaster.

Break the API/ABI for tdb2 and have done with it - it's a separate
library.

Jeremy.