Hi Andreas, Andreas Jellinghaus wrote: > the code looks good to me. very clean, nice!
Thanks. > 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? > * 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. 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). > * 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. > 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). 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. > > 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. 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... > > 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. But there is no really abstraction (yet). Only the generic 'ifd_open_direct()' and 'ifd_direct_close()' are useful, to distinguish between access types. > > - 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. Hmm, but CWI and BWI seem to be used to detect communication errors and the end of communication transfers. Someone should check for these values when a data transfer is running. As OpenCT only calls for the complete answer data set, I guessed my userland driver (= firmware on other external card readers) has to check these values. But I'm not sure. Any card reader firmware developer around here? > > * 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. But how to detect if card's answer is complete? > > * 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. Ahh, okay. More than one PPS would/should be possible. > also not sure 100% how higher level APIs work, but I thought > apps need to trigger PPS? Seems so. Driver's 'set_protocol' will be called to negotiate. Don't know if the driver should do it by itself if this function does not get called. > 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...) 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? > > 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. 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... > [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. 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. > > * Even running "openct-control shutdown" seems not to call the > > driver's 'close' function. Bug or feature? > > guess a bug. Okay. Regards, Juergen _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
