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