[SSSD] [PATCH] DATA_PROVIDER: BE_REQ as string in log message

Petr Cech pcech at redhat.com
Tue Aug 18 11:19:02 UTC 2015


On 08/05/2015 11:23 AM, Jakub Hrozek wrote:
>>> B)
>>> > >While writing a patch Lukas noticed another similar logging messages
>>>> > >>[sssd[pam]] [sss_dp_get_account_msg] (0x0400): Creating request for
>>> > >[LDAP][3][1][name=mof_user6]
>>> > >
>>> > >I investigated it. This is the same thing -- BE_REQ_*, but it is no longer
>>> > >in the provider, but in the responder. Can you please advise me where I
>>> > >could the function 'be_req2str' write?
>> >I think you should move it to separate file, as you don't want to share more
>> >code then necessary.
>> >There are 2 possibilities where to have this file
>> >a) in src/providers  - responders already link with some modules from this
>> >folder, so I suppose it's viable
> Yes, this is a bit of hierarchy violation, but in the end we need to
> share the constants somehow. I think it's fine to keep the definite
> version in the providers/dp_* hierarchy, because that's where the
> interface is defined, the responder is a consumer.
>
There is new patch attached.

I think, that constants and const2str() functions should be in one 
place. I tried to suggest how we might share our constants. That's why I 
created a new header file in which we could move all the constants in 
the future.

I am open to discussion. I look forward to your views.

Petr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-DATA_PROVIDER-BE_REQ-as-string-in-log-message.patch
Type: text/x-patch
Size: 17724 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20150818/05a0b2ea/attachment.bin>


More information about the sssd-devel mailing list