Re: [opensc-devel] SC_FUNC_RETURN and ctx-debug = level (/branches/martin/0.12)
Hi! Martin Paljak: Privet, On 14.09.2009, at 14:57, Aktiv Co. Aleksey Samsonov wrote: Patch for /branches/martin/0.12 revision 3732 is in attachment: rollback check (ctx-debug = level) in SC_FUNC_RETURN macro. Martin, could you please add it? Thanks for double-checking, applied/rolled back in r3733 In my patch http://www.opensc-project.org/pipermail/opensc-devel/attachments/20090914/45072333/attachment.txt there were not these http://www.opensc-project.org/opensc/changeset/3734 spaces. I'm trying to make these patches as convenient as possible to use. But it seemed that my patch was not convenient. Could you please tell because of what? So, either: - log level concept can be removed (0/1) altogether - or levels can be better defined and limited (3, not more than 4 levels with more well-defined purposes) and a SC_DEBUG macro with a level parameter created. code in log.c checks for debug level 0 so redundant = 1 style checks are scattered across files. Unlike long-running processes (servers) I have personally not found a reason to have some debug when I really need as much debug as possible from OpenSC, partly because I don't know which smaller than 9 number would give not too much garbage but enough information to be useful. In normal situations everything should just work and no debug log generated at all, but when things break it is always the best to have as much logs as possible. Thoughts? I consider, that different levels of debug prints are very useful. First of all developers need them, especially for developing of a new code, not for correcting mistakes. It is easy-to-use (handy) to see the log only from the level which you need or only of detail which you need. I think that in core files we have to more deliberate and better defined the output's level, but not to change the system and keep the levels up to 6. We may have defined from 0 to 6 levels, but for developers of card-drivers more than 6 levels may be allowed. Martin, if we replace everywhere sc_error to sc_debug, then how we provide details/reasons/tips to the user, and not just SC_ERROR_NOT_SUPPORTED (eg see src/pkcs15init/pkcs15-rtecp.c:rtecp_create_pin)? Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SC_FUNC_RETURN and ctx-debug = level (/branches/martin/0.12)
On 16.09.2009, at 16:01, Aktiv Co. Aleksey Samsonov wrote: Thanks for double-checking, applied/rolled back in r3733 In my patch http://www.opensc-project.org/pipermail/opensc-devel/attachments/20090914/45072333/attachment.txt there were not these http://www.opensc-project.org/opensc/changeset/3734 spaces. I'm trying to make these patches as convenient as possible to use. But it seemed that my patch was not convenient. Could you please tell because of what? On mac Mail.app (and now checking, also gmail does it) shows the patch inline so I copypasted it into an editor, saved, applied; apparently some extra spaces got into the new patch file. Sorry for the confusion, noticed it and corrected it. Thoughts? I consider, that different levels of debug prints are very useful. First of all developers need them, especially for developing of a new code, not for correcting mistakes. It is easy-to-use (handy) to see the log only from the level which you need or only of detail which you need. Agreed. And more functions could be improved with SC_FUNC_CALLED and SC_FUNC_RET macros, after some more exact levels have been defined. I think that in core files we have to more deliberate and better defined the output's level, but not to change the system and keep the levels up to 6. We may have defined from 0 to 6 levels, but for developers of card-drivers more than 6 levels may be allowed. Good idea - define some levels to be used in core files (but maybe less than 6) and higher levels are for card drivers. 0 equals no debugging so is not used; 1 for informational events like binding done, shutting down, applet version etc, 2 for important decision points, 3 for function called/returned, 4 for really verbose, 5 for APDU logging. The rest is up to card drivers? Martin, if we replace everywhere sc_error to sc_debug, then how we provide details/reasons/tips to the user, and not just SC_ERROR_NOT_SUPPORTED (eg see src/pkcs15init/pkcs15- rtecp.c:rtecp_create_pin)? Interesting example. OpenSC consists of two things: two API-s (libopensc in lower level and PKCS#11 on top of it) and a bunch of utilities. API-s are supposed to be used by programmers and by programs. Programs can be headless (Firefox for example, pam_pkcs11) and disconnected from a terminal UI. API-s communicate with return codes and you debug them with a debug log if something goes wrong. Utilities are supposed to be used by end-users and their purpose is to translate the underlying error situations into human readable descriptions. This is why I replaced sc_error in src/tools/* with fprintf(stderr) and sc_error everywhere else to sc_debug() One option would be extending the ui.c/ui.h scheme with actual methods for such communication, but: I don't know exactly the relations of pkcs15init as a separate library, PKCS#11 module and pkcs15-init. For example, if/when/how/how often pkcs15init is called via PKCS#11 and how much it is used via pkcs15-init from a terminal. Most of the time I use pkcs15-init from the command line and then the PKCS#11 module when I actually use the personalized card. I've never initialized a card via PKCS#11 or changed anything than a PIN code via the module. Until somebody explains it to me I would personally create a single library/single DLL: libopensc.so with everything in it; use command line utilities to personalize the card (pkcs15-init) and PKCS#11 for the rest of it. If the rtecp_create_pin function is called via PKCS#11 then there is no guarantee that message ever reaches the user and you have to give a good enough return code instead. If it is called from pkcs15-init (especially if called *only* from pcks15-init) then it makes sense to use fprintf(stderr) instead or modify the way pkcs15-init and pkcs15init library communicate to be able to pass more information. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] SC_FUNC_RETURN and ctx-debug = level (/branches/martin/0.12)
Hello!
Patch for /branches/martin/0.12 revision 3732 is in attachment: rollback
check (ctx-debug = level) in SC_FUNC_RETURN macro.
Martin, could you please add it?
Thanks
diff -u -r 0.12-r3732/src/libopensc/log.h 0.12-r3732_new/src/libopensc/log.h
--- 0.12-r3732/src/libopensc/log.h 2009-09-14 09:35:14.0 +0400
+++ 0.12-r3732_new/src/libopensc/log.h 2009-09-14 15:40:03.0 +0400
@@ -59,7 +59,9 @@
#define SC_FUNC_RETURN(ctx, level, r) do { \
int _ret = r; \
- sc_do_log(ctx, SC_LOG_TYPE_DEBUG, __FILE__, __LINE__, __FUNCTION__,
returning with: %d\n, _ret); \
+ if (ctx-debug = level) { \
+ sc_do_log(ctx, SC_LOG_TYPE_DEBUG, __FILE__, __LINE__,
__FUNCTION__, returning with: %d\n, _ret); \
+ } \
return _ret; \
} while(0)
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SC_FUNC_RETURN and ctx-debug = level (/branches/martin/0.12)
Privet, On 14.09.2009, at 14:57, Aktiv Co. Aleksey Samsonov wrote: Patch for /branches/martin/0.12 revision 3732 is in attachment: rollback check (ctx-debug = level) in SC_FUNC_RETURN macro. Martin, could you please add it? Thanks for double-checking, applied/rolled back in r3733 This brings me to another issue I wanted to ask from fellow developers: some kind of order in the debug level usage, as currently it ranges from 0 to 4 in SC_* macros. sc_debug() does not take a level option to allow the developer to specify a level of interest to the debug message and so there are 200+ manual if checks for levels ranging from 0 to 6 in different code files. Controlling debug output and level is controlled by a number in the config file but as much as I've had to instruct somebody to enable logging I say write 9 to opensc.conf and send me the output as a all or nothing approach. So, either: - log level concept can be removed (0/1) altogether - or levels can be better defined and limited (3, not more than 4 levels with more well-defined purposes) and a SC_DEBUG macro with a level parameter created. code in log.c checks for debug level 0 so redundant = 1 style checks are scattered across files. Unlike long-running processes (servers) I have personally not found a reason to have some debug when I really need as much debug as possible from OpenSC, partly because I don't know which smaller than 9 number would give not too much garbage but enough information to be useful. In normal situations everything should just work and no debug log generated at all, but when things break it is always the best to have as much logs as possible. Thoughts? -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
