Doug, Yes, the proposed change would work.
Thanks, Brian Thomas -----Original Message----- From: Douglas E. Engert [mailto:deeng...@anl.gov] Sent: Monday, January 24, 2011 2:11 PM To: Brian Thomas Cc: Martin Paljak; opensc-devel@lists.opensc-project.org Subject: Re: [opensc-devel] Proposed cardmod patch 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. 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. Would that work? > > Thanks, > Brian Thomas > > -----Original Message----- > From: Martin Paljak [mailto:mar...@martinpaljak.net] > Sent: Saturday, January 22, 2011 7:27 AM > To: Douglas E. Engert > Cc: opensc-devel@lists.opensc-project.org; Brian Thomas > Subject: Re: [opensc-devel] Proposed cardmod patch > > Hello, > > On Jan 21, 2011, at 9:45 PM, Douglas E. Engert wrote: > >> Attached is the patch to just do (2) below. I believe that this >> is the part that Brian wants to not call sc_ctx_detect_readers >> Martin you had said you want to do this differently so I will >> leave this up to you as to weither this is commited or not. >> On 1/19/2011 5:46 PM, Douglas E. Engert wrote: >>> (2) Implement a change that this should work for Brian Thomas >>> that allows one to not detect the reader when creating >>> the sc_context. This uses the >>> SC_CONTEXT_PARAM_DONT_DETECT_READERS flag in the ctx_params >>> >>> (The more I think about this, this should be the default >>> to not detect the readers during the sc_create_ctx, as >>> a flag on opensc.conf could control this instead.) > > > Before adding any flags, the real reason for it should be identified. > If the reason is behavior of OpenSC internals when used for a MS > MiniDriver implementation, the requirements should be clear and > communicatable: > > * context and card handles are handed in by the minidriver code instead > of OpenSC having to detect them itself during context creation (through > context creation parameters of course) > * detecting of readers other than the given reader make no sense and/or > can cause unwanted side effects (side effects and bugs should be fixed > separately or not allowed function chaining be documented) > * what happens or should not happen during sc_context_create() has not > been documented anywhere (but should, no matter which of the following > is implemented) > > I suggest to > a) remove the flags member from context parameters (until there is a > need for flags) > b1) remove the call to sc_detect_readers() in sc_context_create() and > document the behavior of sc_context_create(), delegating reader > detection responsibility to the application (command line utility or API > bridge like PKCS#11 or Tokend or CSP) > OR > b2) based on the passed in parameters, behave as expected when context > and card handle are passed in (don't list readers, fetch the reader > properties (name, protocol) from the card handle etc), extending > reader-pcsc.c if needed to support a different initialization method. > Normal context creation would still behave the same way as currently, by > detecting available readers during context creation time. > (eventually c)) fix reader-pcsc.c by removing the cardmod copy case and > adjusting reader-pcsc.c to to handle the restrictions of minidriver use > (code restrictions based on the mode of driver initialization which can > further be narrowed to Windows only ifdefs) > > I don't really have a preference, either is good, with b1 being a > simpler change at the moment but b2 combined with c being necessary in > the long run. > > If the need is because of something different and the above does not > fit, Brian needs to come up with a better excuse than "we need this > because we just do" ;) > > > Cheers, -- Douglas E. Engert <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
