[SSSD] [PATCH] Keep sysdb context in domain info struct

Stephen Gallagher sgallagh at redhat.com
Tue Jan 31 12:18:10 UTC 2012


On Tue, 2012-01-31 at 09:36 +0100, Sumit Bose wrote:
> On Mon, Jan 30, 2012 at 09:31:14PM -0500, Stephen Gallagher wrote:
> > On Wed, 2012-01-25 at 18:12 +0100, Sumit Bose wrote:
> > > Hi,
> > > 
> > > a few days ago I send a draft patch where the sysdb context is stored
> > > in the domain info struct. I created a patch which is a bot more
> > > conservative than the last one and included the comments by Simo (added
> > > a destructor and don't unconditionally add the context all the time).
> > > 
> > > This patch will make the handling of sub-domains much easier, because
> > > now only the domain info struct for the sub-domains needs to be
> > > up-to-date.
> > 
> > 
> > Nack.
> > 
> > To save ourselves some cycles, if we go through the search in
> > sysdb_get_ctx_from_list(), it would be best to assign the sysdb context
> > to the domain once it's discovered. That said, I'm confused why we would
> > ever hit that code. I'm somewhat inclined to remove it and just always
> > return the domain->sysdb value and see if anything blows up and fix that
> > instead.
> 
> ok, this was my first idea as well, but then I thought it might be
> better to be conservative here and look for the debug message from some
> time to see if this path is ever taken.
> 
> Would you prefer to keep sysdb_get_ctx_from_list() and let it just
> return domain->sysdb or shall I remove it completely and let the caller
> just take domain->sysdb and check for NULL?

Actually, let's eliminate the sysdb_get_ctx_from_list() and just take
domain->sysdb. If it's NULL, throw a level 0 DEBUG message so we will
see it and fix it immediately.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120131/09fb6e28/attachment.sig>


More information about the sssd-devel mailing list