[PATCHES] Cleanup, compact and simplify some sbus code

[Simo Sorce]

This set of patches is the result of my taking a second look at the sbus
code. One of the driving factors was the removal of talloc_reference()
given the uncertainty about this API upstream.

During the review I decided to rationalize the use of names, combined
server and connection structures so that one single set of watch
functions can be used without the need of additional placeholder
structures (I've done this in 2 steps with a placeholder structure
first).

Finally I found some minor bugs and potential memory leaks I resolved in
patches. One notable bug that was hiding in the code is that the
responder context was holding only one sbus_connection structure and we
were assigning to it both the monitor and the dp connection structures.
We don't reference the monitor connection after we instantiate it so if
the monitor connection was set up first we wouldn't notice it.
With my patches I started seeing that the dp connection was set up first
some times and this led to failures as messages intended for the data
provider were received by the monitor, and it would reply with a Method
Unknown error of course.

Simo.

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/06/2009 05:47 AM, Simo Sorce wrote:
>  This set of patches is the result of my taking a second look at the
> sbus
>  code. One of the driving factors was the removal of talloc_reference()
>  given the uncertainty about this API upstream.
>  
>  During the review I decided to rationalize the use of names, combined
>  server and connection structures so that one single set of watch
>  functions can be used without the need of additional placeholder
>  structures (I've done this in 2 steps with a placeholder structure
>  first).
>  
>  Finally I found some minor bugs and potential memory leaks I resolved in
>  patches. One notable bug that was hiding in the code is that the
>  responder context was holding only one sbus_connection structure and we
>  were assigning to it both the monitor and the dp connection structures.
>  We don't reference the monitor connection after we instantiate it so if
>  the monitor connection was set up first we wouldn't notice it.
>  With my patches I started seeing that the dp connection was set up first
>  some times and this led to failures as messages intended for the data
>  provider were received by the monitor, and it would reply with a Method
>  Unknown error of course.
>  
>  Simo.
>  
>  
>  ------------------------------------------------------------------------
>  
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/sssd-devel 

All six patches are acked.

- -- 
Stephen Gallagher
RHCE 804006346421761

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkqAIoIACgkQeiVVYja6o6NU/QCgn1UP9MIWHR/cNmCrQfuVGCLE
> IHAAn1BTY85tUH45XgUZs17CT0c4xZl3
> =WqqP
> -----END PGP SIGNATURE-----

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/10/2009 09:37 AM, Stephen Gallagher wrote:
>  On 08/06/2009 05:47 AM, Simo Sorce wrote:
> > This set of patches is the result of my taking a second look at the sbus
> > code. One of the driving factors was the removal of talloc_reference()
> > given the uncertainty about this API upstream.
>  
> > During the review I decided to rationalize the use of names, combined
> > server and connection structures so that one single set of watch
> > functions can be used without the need of additional placeholder
> > structures (I've done this in 2 steps with a placeholder structure
> > first).
>  
> > Finally I found some minor bugs and potential memory leaks I resolved in
> > patches. One notable bug that was hiding in the code is that the
> > responder context was holding only one sbus_connection structure and we
> > were assigning to it both the monitor and the dp connection structures.
> > We don't reference the monitor connection after we instantiate it so if
> > the monitor connection was set up first we wouldn't notice it.
> > With my patches I started seeing that the dp connection was set up first
> > some times and this led to failures as messages intended for the data
> > provider were received by the monitor, and it would reply with a Method
> > Unknown error of course.
>  
> > Simo.
>  
>  
> > ------------------------------------------------------------------------
>  
> > _______________________________________________
> > sssd-devel mailing list
> > sssd-devel(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/sssd-devel
>  
>  
>  All six patches are acked.
>   
Pushed to master.
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

- -- 
Stephen Gallagher
RHCE 804006346421761

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkqAI+0ACgkQeiVVYja6o6OtgwCeKpOzluXeHvNtpMoqg4bjaLoO
> nfEAn2BTBGb4tvHi9ypSfBdpTnjB5MVH
> =A3b1
> -----END PGP SIGNATURE-----