On (13/07/15 10:57), Jakub Hrozek wrote:
>On Mon, Jul 13, 2015 at 09:47:46AM +0200, Lukas Slebodnik wrote:
>> On (10/07/15 16:54), Jakub Hrozek wrote:
>> >On Wed, Jul 08, 2015 at 03:26:52PM +0200, Sumit Bose wrote:
>> >>   I would suggest that you put sss_cli_command_2string() in a file on
>> >>   its own similar like atomic_io.c or authtok-utils.c. And add this file
>> >>   to pam_sss_la_SOURCES and libsss_debug_la_SOURCES in Makefile.am. I
>> >>   leave it up to you to decide what would be a good place for this file.
>> >>   The sss_client directory because the enum sss_cli_command is defined
>> >>   here as well or the util directory because the main usage for it is in
>> >>   the SSSD code and not in the pam_sss module.
>> >
>> >This is really important, so much that I wonder if we should move all
>> >the files that are used by both client code and daemon code to some new
>> >directory in the SSSD tree (src/shared/ maybe) and use a different comment
>> >header in these files.
>> We do not need to use sss_cmd2str in client code.
>> If you wan to see debug messages from pam_sss module then you
>> need to recompile source code with extra CFLAG to enable them.
>
>Good point.
>
>> 
>> It very unlikely that debug messages in pam_sss code will used by users.
>> I would prefer do not touch client code or used just hexadecimal
>> represaentation (the same as in header file)
>
>I agree, let's not touch the client unless needed.
Another reason for not using sss_cmd2str in client code is that
it depends on our "debug_fn" from internal library libsss_debug.

Even thought the function sss_cmd2str was not used in pam_sss.c
it was still linked with pam_sss.so and thus dlopen test failed.
Petr already noticed it; This mail is just summary of off the list
discussion.

LS
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

Reply via email to