tdb_chainlock() in tdb1, tdb2 and tdb_compat ?

[Jelmer Vernooij]

On Fri, Apr 13, 2012 at 10:50:15AM +0200, Volker Lendecke wrote:
> On Fri, Apr 13, 2012 at 10:41:10AM +0200, Michael Adam wrote:
> > I understand that there is a real problem with the
> > sublte difference in signature and return semantics for
> > tdb_chainlock.
> > 
> > There can always be new callers that check == -1 instead of < 0,
> > so I think the best way would have been to have a compat
> > version for these, too, so that the difference is explicit.
> > 
> > I also think simo's proposal was quite reasonable,
> > but the middle course might be to consequently use the compat
> > layer for such functions as chainlock for which the compiler does
> > not complain about differences (at least the C compiler...).
> > 
> > For the demand of samba3 still being able to link against
> > system libtdb (version 1.X), couldn't we introduce tdb into
> > libreplace and do some #define trickts? ...
> 
> Different proposal: Rename tdb2 to tdb3 and introduce a tdb2
> version that matches exactly tdb1 code with 2 changes:
> tdb_off_t is uint64 and the freelist becomes a doubly linked
> list. This way we solve the two pressing tdb1 problems
> without a lot of the hassle that tdb2's semantic changes
> bring. I checked: tdb_off_t does not leak into the published
> API. We would probably limit a single record to 4GB, but I
> doubt this is a real issue.
That seems a lot simpler indeed. We could do that in the existing
lib/tdb directory, without having to worry about supporting
two distinct APIs in Samba.

How important are these two fixes though? Do we really have to do them
before 4.0, or could they reasonably be deferred until 4.1 along with
the rest of tdb2?

I think we should move to tdb2 eventually, but trying to support both
tdb1 and tdb2 does add a fair bit of complexity (in terms of
the build system and other code) with no huge gains at this
point. We seem to have enough distractions for 4.0 as is.

Cheers,

Jelmer