tdb_chainlock() in tdb1, tdb2 and tdb_compat ?

Andrew Bartlett abartlet at
Thu Apr 12 18:37:42 MDT 2012

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.

There are certainly a lot of issues with the nature and timing of the
introduction of tdb2 to Samba, but one of the advantages of the waf
build system is that the duplicate symbol issue you fear won't happen.
tdb2 is a versioned library, and so the symbol won't collide with any
static or imported tdb1 symbol. 

We know this works because we rely on it for the rest of Samba, which we
run on systems with MIT kerberos and embedded Heimdal (including in
bind9, and evolution via OpenChange).  Indeed, it was exactly this kind
of real-world issue that brought symbol versions to waf.  The duplicate
symbol detection code also verifies that this operates correctly, as it
also checks against system libraries we link in. 

I hope this clarifies things,

Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 

More information about the samba-technical mailing list