De : Martin Paljak <mar...@paljak.pri.ee> A: François Leblanc <francois.lebl...@cev-sa.com> Cc : opensc-devel@lists.opensc-project.org Date: 24/09/2010 10:14 Objet : Re: [opensc-devel] Patch to let carmod working after multiple reader system removal.
>Hello François, > >Can you please configure you mail client to not send HTML messages to the list? Ok Guillaume Jean give me tip to do it, hope this time it's working... >On Sep 24, 2010, at 9:08 AM, francois.lebl...@cev-sa.com wrote: >> >Please describe how the driver is used by the minidriver, how it differs from "normal" OpenSC use, what are the biggest and most >>important differences between the "normal" pcsc code and the cardmod code. >> >> This has already been discuted summary windows process provide pcsc handle and context and you need to use them >> you can't open context, create handle and access to the card (it's the goal to use opensc under windows) >> >> When you insert card under windows, windows detect this insertion open context and create handle with card and give you >> this informations to your dll to manage card, so you can see that with this process you can'ty create handle to your card since >> the card is already connected ... > >That's the description what BaseCSP does with PC/SC handles. It does not describe possible solutions how to accommodate the >requirement in OpenSC. Nor how the rest of OpenSC should cope with it. Possible solution to accomodate the requirement have already be seen, I've choice one, you talk about another one with env varables (for me env or registry is quite the same and don't change really the trouble...) For the rest of opensc I don't see what you mean opensc should work like it do now... >> >Minidriver code calls sc_create_context like other applications, with the difference that a card handle is already present in >the >minidriver code and does not need to be fetched via libopensc calls and connected to with a sc_connect >> >So you decided you pass the handles around to the libopensc instance in windows registry (not environment variables as was in >>another incarnation of OpenSC + BaseCSP). >> Could you provide working example of incarnation of OpenSC + BaseCSP ? >I don't know how much the code @ [1] works or not, but I'm talking about passing in the context and card handle. > > >> >This means a single instance of an OpenSC based card and reader by default. Why not use the context creation parameters to pass >in >> After start of process an another one with other hanlde can be started... >I'm not convinced in windows registry being the best medium for function parameter passing. Ok, feel free to implement another one, doesn't mind for me, my goal is to provide something working and that we can improve... >> >the necessary handles? There is no IPC present and necessary modifications to the context creation functionality to accommodate >>BaseCSP requirements is perfectly reasonable argument to change those structures and add code. Especially now, when it is not >>exposed to outside world. >> >> I'm ok to pass pcsc handle and context with in the creation context parameters, but these are needing under pcsc driver, so >> I need a link between context creation parameters and reader-pcsc, this need more modification that using registry, or I miss >something... >(See below) Ok, but you talk abourt a csp not a BaseCsp minidriver, is quite different. >> >Having a single reader driver greatly simplifies the architecture of OpenSC. It also simplifies the proper modifications needed >for >the "cardmod" driver. You are free to patch the libopensc instance at runtime any way you want to get what you need. This >means >overloading the not needed functions from pcsc driver with NULL. And adding necessary logic to the rest of PC/SC functions >to >return early as needed. >> >As is the case with the rest of reader driver, the decision what to build happens not at runtime, but at compile time. There are >>several restrictions to what can be put inside a minidriver, so I would build it as a single static dll instead. >> >> I don't understand exactly what you mean, but I'm agree with the end building in one static dll will be better, unfortunatly I >don't known how to process for now. >Necessary modifications to context creation and the pcsc driver can be done with #ifdef ENABLE_CARDMOD. > >To be able to include the minidriver in the windows installer and to be able to develop it further, it would be nice to have: > * the purpose, definition, and overall architecture described, so that something could be understood without digging through the >code. Ok added some link to wiki page, Microsoft will explain it better than me. > * easily buildable and the build process repeatable, with enough instructions in the wiki to accomplish this The build process is already integrated. Instruction to build are provided. If one have trouble to build send list message and we will see how to improve process or complete documentation... > * properly integrated with OpenSC, this means both pcsc requirements as necessary context handling requirements and whatever else >is needed. This don't meet the trouble to build static dll, since cardmod is working requirements and else are filled. What is needed is how to include libopensc.dll and other used by opensc (opensc and not cardmod, requirements are opensc requirements not cardmod requirements) to be static in opensc-cardmod.dll it's this point that I don't known how to do. I don't understand why you need to known the complete process how work opensc-cardmod.dll etc etc just to build a static dll compound of the actual cardmod.c and libopensc.dll (+ other dll used by libopensc like libtool etc etc)? It's not possible to do this? Perhaps Alon who seems to know very well autotools can help to answer this question? >[1] http://itacns.corp.it/hg/itacns/ > >-- >@MartinPaljak.net >+3725156495 Regards, François _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
