the code looks good to me. very clean, nice! what is missing are some small issues: * license: LGPL-2.1+? or 3-BSD? or some other license? * the whole picture: if someone has a patched kernel and openct with these changes: how does he get it to work? "mknod" to create a device and a static config in openct.conf? or sysfs, udev and hotplugging? (if so, what changes are needed for udev...?) if the big picture is described somewhere, a url would be fine too. * kernel patch: is it published somewhere? we could carry a copy from my point of view, or a txt file with a url in it or something like that (or simply edit openct wiki and create a new page, and possibly attach it, if you like).
> The kernel driver is not part of this patch stack. Please bear with me, if > the SmartCard handling seems broken at any point. I'm not a SmartCard > expert. This is my first attempt to make them work. do you have some card and app for testing? opensc and a cardos card for example, and running the opensc regression test suite. > > Some notes: > - I'm not sure if something like the 'src/ifd/direct.c' is really > required. I wrote it to get my userland driver to work and to be able to > setup my interface in the same manner like the other reader's drivers. > Most functions are dead in this file, because the communication to 'in > kernel' drivers is much simpler than talking to a serial or USB device. > Suggestions to avoid this file are welcome. hmm, not sure if "direct" is such a good name, but I don't know a better one myself. in general keeping that abstraction is ok with me. > - there was the need to touch 'src/ifd/atr.c' to be able to calculate some > timeout values. If there is a generic way to extract the CWI/BWI related > to a specific protocol, please give me a hint. I think for the other > reader devices, this kind of calculation is done in their firmware, right? not sure, maybe openct lacks proper handling there. At last I never bothered with all that, since usb crypto tokens are often very fast by default. > * what is the default 'block waiting time' for the T0 protocol? I thought T=0 is character based, so there should be none...? but no expert here, only used T=1 devices myself. > * what is the correct behaviour, if the card wants to use a > specific FI/DI pair, the hardware cannot handle? the card lists in atr what it can do. the reader doesn't need to do pps, it can stay at the default speed. or it can use PPS with any fi/di it wants, not only the one listed in the atr. if the card accepts that fi/di in pps communication, both sides are fine with it. also not sure 100% how higher level APIs work, but I thought apps need to trigger PPS? still many readers do pps by themself, so cards are always as fast as possible with them, at least I think. (well, at least drivers for windows might do that...) > Falling back to 1/1, or trying to use a FI/DI pair with slower transfer speed? I'm using the > latter one, but I'm unsure if its correct. And what to do, if the FI value > is supported, but the DI value is to small? (for example: Card wants > FI/DI=13/1, but my interface can only handle 13/2, 13/3, ...) 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. [power management] hmm, good idea. if noone keeps a connection to the reader open, it could be suspended and everything turned off. however is some app keeps a connection open, it must stay active, so that a "verified" state (pin confirmed) isn't lost due to a power down. > * Even running "openct-control shutdown" seems not to call the driver's > 'close' function. Bug or feature? guess a bug. Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
