Am Donnerstag 20 Mai 2010, um 10:11:03 schrieb Juergen Beisert: > That's exactly what I have. But to bring such kind of driver into the > mainline kernel, the API to the kernel space must be more generic. That's > the reason, why I'm asking for more uses cases for these SmartCards than I > have with my small (and special) hardware.
hmm. I still would try to keep it as simple and small as possible. a larger API with functions noone implements simply rots, and isn't helping anyone. > Currently I'm using a simple char device node. sounds good. > I'm a kernel hacker. Writing kernel drivers is my daily job. But defining > an API for SmartCard interfaces isn't. the problem: in my opinion the interface to smart card readers is defined with serial ports (e.g. how to access a serial port device such as a towitoko smart card reader) or with usb (user space communication towards a usb reader, for example those implementing CCID or ICCD standard). so the "implement a smart card reader" is mostly user space, and the kernel only provides the generic transport mechanism from user space to the device on the other side of the cable. I would try to keep it that way. don't implement t=0 or t=1 in kernel etc. > Yes, that's why I'm asking here. Defining an API for SmartCard interfaces > in a way, to make life easy for people using these userland projects (or > developing drivers for). I'd rather say: you have a device attached via a reduced version of a serial port.not a generic one (then you could use std. serial port driver and do everything in user space), but a somehow reduced one, and you need to hide that details. but if your hardware has extra features that don't map to a std. serial port, I don't know what to do. how do the driver for serial towotoko readers implement the same feature? maybe some special signaling - i.e. like catching some APDU commands and acting on them? no idea. with a pc you have your cpu and then a firmware in some microchip inside the reader, I guess. so that part would need to be in the kernel? not sure. > > better not use openct+pcsc-lite combo, it can work, but needs to be > > tested well. > > Then I'm a tester. My current test case is a small test program using PCSC > to talk to a SmartCard via an ifdhandler from the OpenCT + my OpenCT > driver + my kernel driver. At least my test case works. great! that is good news. if you have one of the cards supported by opensc completely, you could later run the regression tests in opensc source src/tests/regression directory. if they work fine, you know that pretty heavy communication works. > Currently I should support SmartCard/SIM and its specific type of > communication. For other interfaces (like I2C) other frameworks in the > kernel do exist. yes. but I have no clue how to implement a generic interface. seems that in real world (e.g. windows), every vendor has a special proprietory library with their own "extensions" to handle memory cards too. > > > > What else must a generic API to the kernel handle, to control all > > > features of SmartCards interfaces? Attached my current approach to > > > define some IOCTLs to control the interface to the SmartCard. > > > > too much (please keep t=0 and t=1 in userspace in stead of kernel), and > > not enough (which frequencies does your hardware use with the card)? > > > > I think > > - read data > > - write data > > - warm reset > > - hard reset > > - get card status (card / no card / card removed and added again) > > - reader frequency > > What does "reader frequency" mean? The clock, the reader provides to the > SmartCard? Or something different? yes. I don't know much about those low level details, but the real communication speed isn't only controlled by fi and di negotiated during PPS, but also by the clock frequency used by the reader. in datasheets I often see "up to ...", but as poweruser I would like to know, what frequency the reader uses right now. > I saw other readers are also able to lock the card. Also a useful case? lock? like if you have an ATM where some hardware based mechanism cuts the connection to the outside, so you can't insert a card with a cable connecting it to your laptop? sure, I guess some readers have that. but I guess the kernel has generic framework for strange features like that (e.g. input system that can map to arbitrary special keys/buttons on any device, and also work the other way, unless I'm mistaken), so maybe it is easier if you have two interfaces for that - one to control such hardware and one for the chip communication, than to have a complex one for both. not sure about that... Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
