Hi Andreas, Andreas Jellinghaus wrote: > Am Mittwoch 19 Mai 2010, um 15:32:22 schrieb Juergen Beisert: > > I don't know if this is the correct list to ask this question. If not, > > please give me a pointer. > > muscle list has even more experts on writing drivers I guess, > but opensc-devel should be fine, too. > > > 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? > > hmm. I guess there are embedded people with similar projects. For example > I read about people writing NFC stacks for Android mobile phones, I guess > they will have similar situations. > > > I asked on the kernel maillist and the most important thing is to define > > an API used between any userland application and the kernel driver to > > control the interface to the SmartCard (the communication itself is > > handled with simple read()/write()). > > write a minimal driver that can setup a char device, so you can read and > write, and maybe supports some ioctl (e.g. to set speed / get speed etc.). > but: I never did something like that, so this is pure theoretical thinking.
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. > and some sysfs stuff, so you can "find" the device (i.e. udev knows what > to create and the minor/major number to use). Currently I'm using a simple char device node. > ask on linux-kernel for some good driver that could be used as template. I did. Result: Zero. That's why I have to define the API. > or there are some lists specialised on giving advice and reviews for writing > new kernel driver. I'm a kernel hacker. Writing kernel drivers is my daily job. But defining an API for SmartCard interfaces isn't. > I would minimize the kernel driver, to export a simple and easy interface > (e.g. read/write/speed/reset or so), and leave the rest to useland. > for example T=0 and T=1 and related protocols should be done in userspace Sure. The kernel driver should only transmitt data. It should not know the meaning of the data. > I think, as there is no need for kernel space. plus you don't need to > implement those your self, as there are open source implementations > available (openct, libccid, scez 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). > 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. > (no one is using it, and no one is maintaining it or fixing it, if it > is broken. Good to know. > but might be an option of last resort - getting it to work could > be faster than writing something from scratch.) That's true. I took me only two days to get it work. Thanks to the well designed layering of OpenCT. > > But I'm new to SmartCards and don't know yet, what's required in such an > > API to control all interface features to SmartCards (and my hardware is > > limited to only switch on/off and reset the card, changing to various > > communication parameter and running the communication itself). > > make sure you know exactly what cards you need to support. there are > processor cards based on iso 7816-3 and 4 standard, but there are also > old memory cards that fit the same physical interface, but have very > different protocols (and there are many different protocols for that- > two wire, three wire, many proprietory ones, i2c, ...). > so first make sure what you need to support. sim cards are all iso > 7816-3/4. Currently I should support SmartCard/SIM and its specific type of communication. For other interfaces (like I2C) other frameworks in the kernel do exist. > > 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? > - speed / pps > > should cover most you need. hmm, t=0 has parity bits and stuff maybe too? > not sure, don't know t=0 well. maybe I mix that up with config for > attaching serial readers. > > oh, add ejectif you have a physical way to eject a card. or sensors that > tell you if a card is properly inserted, detected as fake, has a wire to > outside of the atm preventing some gate to close behind the card and > whatever. I saw other readers are also able to lock the card. Also a useful case? Regards, Juergen _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
