On Feb 3, 2010, at 14:28 , Andreas Jellinghaus wrote: >> Consolidating platform components to the opensc svn is good, mungling it >> down the existing source structure not necessarily so good. > > the diffstat is: > configure.ac | 31 > etc/opensc.conf.in | 10 > src/libopensc/Makefile.am | 6 > src/libopensc/ctx.c | 3 > src/libopensc/internal-winscard.h | 2 > src/libopensc/internal.h | 1 > src/libopensc/opensccm.c | 1703 > ++++++++++++++++++++++++++++++++++++++ > src/libopensc/reader-pcsc.c | 358 +++++++ > win32/Makefile.am | 4 > win32/opensccm.inf | 148 +++ > > and the *.reg file for win32 that is missing (was posted last time). > > as far as I can see the modified reader_driver needs to be in libopensc/ > and we need the supporting code (configure, internal changes etc.) for it. > so there is litte we can do different. The API used is still PC/SC, just the way the card handle is received is different.
> so the only variable I see is the placement of opensccm.c > (and the name for it - "cardmod.c" is ok for you?). Yes. > in my opinion a single source file could be placed in a seperate > directory. and we can either create a seperate dll that contains > this extra code and links opensc-2.dll (or includes it static). Yes, see the picture @ http://www.opensc-project.org/opensc/wiki/MiniDriver > but what is best? the extra directory would be fine with me, not > a big deal. but an extra dll? I would prefer not to have that, > we had already enough trouble with the many dlls we had. dll-s are OK if they have a purpose, stuffing many interfaces in a single dll could be useable but not necessarily the best idea. A single interface from a single DLL is the easiest concept to grasp for anyone. > >> The question here is how the "feature" (pre-opened card handles) is >> implemented inside libopensc. The interface towards BaseCSP is indeed >> constant, but the implementation inside libopensc should be reviewed a >> bit, as there have been other (and alternative) implementations. Current >> reader-pcsc.c copypaste does not look like a long-term solution. > > you know that code much better than I do. but didn't the cardmod reader > also share a lot of code with pcsc reader driver? IIRC that was the > argument for keeping it in that file, and not creating a new reader-cardmod.c > file. It is in fact a corner case of the PC/SC driver, not a separate driver. > what do you suggest should be done? and is it ok to commit the patch now > and work on it, or does it have to be changed before it gets into svn? Things required to implement support for existing card handles provided to minidriver should be done as a) conditional code and/or the module built in a separate pass b) smaller code changes in the current code path. Current amount of copypaste should be reduced and should not be commited. >> How do I compile it, where do I download the SDK from? That should be >> documented in the wiki page for example. > > he posted some instructions last time. you need the cardmod.h file from > "Microsoft CNG Development Kit" (plattform SDK might contain it as well), > point configure to it, and you are done. to use it use the reg (older windows) > or inf (newer windows) files. These contain code for the Westcos cards > as far as I understand, and need to be extended to handle other cards > as well. > > btw: François, do you know if several cards can claim one atr? > in that case we could claim all cards - the user can modify opensc.conf > to remove some drivers, thus opensc will not know the card and hopefully > ignore it / leave it to some other software. or can you have only opensc > or some other software installed, but never both? Last time I worked with a minidriver you *had* to have the ATR-s your card is willing to handle in the registry. Installer and registry writer would be necessary. For some reason my build instance did not pick up the cardmod.h file the first two times I tried. The header can not be included in the package for licensing reasons? -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
