Hello, On Jan 24, 2011, at 10:11 PM, Douglas E. Engert wrote: > On 1/24/2011 12:54 PM, Brian Thomas wrote: >> Hello, >> >> I strongly urge the OpenSC team to make this change to fix mini-driver >> compatibility. Yes, my company "needs this because we just do", however >> by implementing this fix, it will ensure better compatibility with a >> Windows mini-driver and thus a more usable product for more people. Brian, you give no insight into how you use and invoke OpenSC, why something does not work (the root cause or more detailed symptoms, other than "context creation hangs for us" ), or what could be the alternative solutions to fix it,.
It is great news that you use OpenSC for your customers (don't forget to make the source code available as well!) but communicating your problem with the source code (not with your customers or managers or deadlines) is the best way to get the attention of fellow developers. That's why a blunt "we need this quickfix patch which works for us within a release before 1 month because we can't afford the V&V (Verification and Validation I assume) effort but we need it for a customer" is not the best excuse. As Peter Stuge said - this is not how open source projects work. Nevertheless, see below for a possible solution to your problem. > Again, I leave this up to Martin to decide if this is the way to go > or not. > > Here is another approach that should also work: > > Split up the current sc_context_create into a new routing > sc_context_create_basic (or some other name) without the call to > sc_ctx_detect_readers. > > A new sc_context_create would then call sc_context_create_basic > and sc_ctx_detect_readers. > > Your code would just call sc_context_create_basic. Attached are three patches (combined into a single file) that should contain the necessary changes to achieve the same in a more consistent way (with more comments in the patch file itself), similar to the option "b1" I described in my earlier mail. The basic change is that sc_context_create should only do the expected (which needs to be documented) - initialize drivers and structures and leave the application logic (like (re-)detecting readers when necessary) to calling applications. I already added the pointers to PC/SC handlers to context parameters, which should be then used to initialize the PC/SC driver. * Remove sc_establish_context, which has been marked as deprecated since r2829 * libopensc: clarify what sc_context_create() does. * general: calling sc_ctx_detect_readers is now the responsibility of the application This should be eventually the only supported entry method into libopensc for usage scenarios similar to minidrivers, where the context and card handles are available at context creation time and other cards and readers should be ignored. This requires more work in reader-pcsc.c, but for a minidriver use case I'd suggest to already set the PC/SC handles in context creation options, which allows to easily remove any reader/card filtering or glue code from the existing hypothetical minidriver when reader-pcsc.c is fixed. This only affects context creation and possible parameter passing, it does not deal with the original problem you encountered: why context creation hangs. The probable984 reason for this is that reader feature (pinpad) detection hangs on a reader which is in use by some other application (or the differences between Windows and pcsc-lite should be tested again..) But as it is not known how you invoke OpenSC, it is hard to say if or how this might be affected. 5186444 482222uyymö
combined.patch
Description: Binary data
Cheers, Martin -- @MartinPaljak.net +3725156495
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
