[RFC] Switch on tdb2 API by default?
Rusty Russell
rusty at rustcorp.com.au
Thu Sep 22 21:53:17 MDT 2011
On Thu, 22 Sep 2011 07:52:25 -0400, simo <idra at samba.org> wrote:
> On Thu, 2011-09-22 at 10:38 +0930, Rusty Russell wrote:
> > Hi all!
> >
> > The TDB2 code (ie. --enable-tdb2) runs in TDB1 mode by default now
> > (there's a tdb_compat shim which inserts the TDB_VERSION1 flag unless
> > the env var TDB_COMPAT_USE_TDB2 is set).
> >
> > So I'd like to make --enable-tdb2 the default now. That way we can
> > test the tdb2 API, and have a run-time flag to enable the tdb2 on-disk
> > format for the brave.
> >
> > This lets us get rid of some compat cruft; for example, tdb2 handles
> > multiple opens internally, so the various db_wrap codes wouldn't have
> > to. We can also add a tdb2 alloc attribute to (finally!) make tdb2 use
> > talloc() for SAMBA.
> >
> > I'm particularly interested in regressions if we turn this on. For
> > example, tdb2 functions return the negative error code, not -1: I think
> > I got all the callers, but new ones may appear.
> >
> > Thoughts?
> > Rusty.
>
> I'd like a more thought out transition. Distributions build TDB
> standalone and this means it will probably require a so name bump and
> relinking of all users.
Yes, tdb2 is a private library at the moment. Once it becomes a
standalone library, it will be libtdb with a larger major soname. At
that point, we're committing to the API.
This is why I'm suggesting we stick with tdb1 compatibility for the
moment: then there's no reason that anyone else needs to upgrade to tdb2
to interact.
This gives us a little more wiggle room if we really want to change
things as we start to use it.
> Also using an environment variable to change
> format seem sort of dangerous to me. Wouldn't it be better to make it an
> explicit option in the new tdb_open (assuming it is not already).
Sorry, I was unclear. It's an explicit flag in tdb2 (TDB_VERSION1).
Adding that unless then env var is set is internal to samba's
lib/tdb_compat.
Hope that clarifies!
Rusty.
More information about the samba-technical
mailing list