tdb_chainlock() in tdb1, tdb2 and tdb_compat ?

[simo]

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.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>