Am Donnerstag 27 Mai 2010, um 10:57:58 schrieb Juergen Beisert: > > what is missing are some small issues: > > * license: LGPL-2.1+? or 3-BSD? or some other license? > > In my next version I replaced the license information by a link to > the 'LGPL-2.1' file. Okay?
ok. best use the template in the license text (at the end). > Ah, you ask for documentation. ;-) OpenCT uses Doxygen. Does it use it also > for user documentation or only for API documentation? I would prefer to > keep code and usage documention together by adding it in docygen style > into the source code. But I'm also fine with adding it to another place > (like the OpenCT homepage for example). no, doxygen use in openct is not really done or maintained. it is bestto edit the openct wiki (although martin is replacing some wikis with the central opensc wiki, I think the openct wiki is not affected - though not sure). or put a txt file into the source with details. > > * kernel patch: is it published somewhere? > > Not yet. I started the discussion here to define the kernel API first. > Publishing it at the kernel maillist will follow now. ok, fine. > There should be no need for any user adding the driver itself to his/her > kernel. Our plan is to bring it into the mainline kernel. very good. > Card and application is customer specific. I will try to get a more useful > card for the regression tests. Hope also OpenSC is cross compile aware... we use standard autoconf/make/libtool with no dirty tricks as far as I know, so it should work, or at least provide a good base. > That is the question: Do the readers the negotiation triggered (and > controlled) by any kind of userland application, or do they do it > internally in their firmware by their own? I think some do it internaly. but pcsc standard dictates the application uses some mechanism to let the driver (ifdhandler) know what speed it wants. > > the card will refuse. not sure if you have several tries in pps > > negotiation, or if you need to reset the card (warm or cold) in between. > > AFIAK some cards are answering with a different ATR when they see a second > reset after they send their first ATR after power up. A perfect negotiation > seems tricky... yes, with warm reset the card can show different ATRs, while with cold reset it will always start with the first. > I don't know the other card readers: In my system I can power down the > card, but I can still continue to check to "card presence" pin. good! Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
