Martin Paljak wrote: > On May 19, 2010, at 18:15 , Juergen Beisert wrote: > > Martin Paljak wrote: > >> On May 19, 2010, at 16:32 , Juergen Beisert wrote: > >>> I don't know if this is the correct list to ask this question. If not, > >>> please give me a pointer. > >>> > >>> Other SmartCard interfaces are built into an external reader (mostly > >>> connected via USB or serial line). My SmartCard interface is built into > >>> a SoC processor running a regular Linux based system. I have written a > >>> small kernel driver to gain access to the hardware (the interface > >>> logic) and also a driver for openct to make userland happy. So, all > >>> software components (application, opensc, openct, driver, SmartCard > >>> interface, SmartCard) are running on the same system. > >>> Are there other people out there who are also using SmartCards in such > >>> a way? So, does it makes sense to support this kind of connection in > >>> openct and/or the kernel? > >> > >> pcsc-lite lately also grew better support for embedded systems. Maybe > >> you'd be interested in integrating the SoC driver with the (more > >> standard) PC/SC interface as well. > >> > >> SoC questions have surfaced quite often lately, so surely you're not > >> alone. > > > > I started with PCSC. But they are not interested in non CCID devices (and > > it seems you have to re-implement the whole communication routines, if > > your device is not a CCID one...). > > Really? Who are "they"?
----- Ludovic Rousseau wrote: If your device is not CCID I see no interest to include it in libccid. ----- > Are you sure you're not mixing up the OSS CCID > driver (which, yes, is meant for CCID compliant USB devices and should not > deal with non-CCID drivers) and the pcsc-lite PC/SC interface/package in > general? Maybe I'm wrong. But I don't saw any way how to implement an ifdhandler for PC/SC and re-use their routines to handle TO/T1 protocol. The ifdhandler in PC/SC has to hide *all* the details of SmartCard communication. This includes the communication protocol. In openct you only have to hide the *access* to the SmartCard. The protocol handling is done in upper layers (BTW: A very good design). > > On the other hand its not a question which userland application is in > > use. Its only a question how to talk to a kernel driver for a SmartCard > > interface in a generic way. > > If there existed a "standard" userspace<->kernel API which different > SoC/embedded platform vendors could implement it would be as useful to the > SoC scene as CCID is to the USB scene. Yes. > Then a single and universal driver (ifdhandler) for pcsc-lite could be > created just as the CCID driver is universal (so-so) for CCID devices. That could be the goal. ------ Alan Cox wrote: The other question is one of API - it's going to best if the API isn't MX25 specific but could reasonably be expected to work with other future devices. ------ > Eventually a stable kernel interface does good, the same way as creating a > pcsc-lite compatible ifdhandler (even if it is more work in the beginning) > does good to the application developers, as it provides the only universal > and cross-platform access layer (PC/SC). But how could this stable kernel interface look? What are the requirements a SmartCard user has to his/her interface: - switching on/off the interface - detecting if a SmartCard is plugged in - resetting the SmartCard - locking the SmartCard - setting up the communication parameters like FI/DI/convention - activating the clock stop mode (to save power) - anything else? > Then again, I don't know how big would be the overlap between embedded and > desktop PC/SC applications. The best would be, if there would be no difference (from the sight of the user). Regards, Juergen _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
