Hello Ludovic, Thank you for replying.
On Tuesday 03 February 2009 12:42:40 Ludovic Rousseau wrote: > I see _many_ advantages to your ideas. I even think of reusing some of them. > What I don't want: > - drop the IFDHandler API and drop support of existing drivers > - engage in a multi-months development. I really prefer an iterative > evolution (of pcsc-lite) instead of a rework from scratch. 1. As I wrote you off list and as I wrote before publicly, the IFDHandle API is not a show stopper. A reader driver of type IFDHandler API can be supported. So you have a reader driver process which loads a specific IFDHandler enabled reader driver. It would be simple enough. In time I believe commonly used drivers may be migrated into new framework, to be more efficient, maintainable and share the common code base available in the reader library. Example: Logging, Protocols, Device Access etc. I wish the CCID driver will be first one to migrate into the new framework. 2. What I offered you is a joint work toward a common goal. We outline the goals from the framework. I implement the framework (which is most of the work). All I needed from you is your commitment that if I achieve the goals we outline, we work together in order to create PC/SC interface using the new framework, and IFD Handler API. I believe we have enough experience in order to specify goals and commit to a process. It will take as much as two years to fully stable release. But at the end users and developers will have much better solution. I think a lot has changed since year 2000. Design practices were changed from blocking, threaded, single process model to none blocking, single threaded model. The number of popular operating system reduces... We have about 2.5 (Linux, BSD, Solaris). New APIs were added to ease event management. The hotplug services are matured. And we don't have enough resources to maintain duplicity. My own personal process.... I started from making Open Source projects support smartcards via PKCS#11, done OpenSSH, OpenVPN, GnuPG, QCA, eCryptfs, GnuTLS and even tried to help mySQL. OpenSC is a great effort trying to join efforts and support as much devices as possible. The vision is great. So I fixed OpenSC PKCS#11 implementation to actually work (fork(), plug&play etc...). Then I needed OpenSC work on Windows so I rewrote the build system and added mingw32, mingw64 support. Now we can use single build system to all platforms. After that I found pcsc-lite is unusable/stable for my configurations, so I switched to openct, and improve it to meet my requirements with much help from Chaskiel M Grundman (ccid-1.10, remove libusb, none root, event driven). We have much work in OpenSC, mainly remove the one application session limitation (stateless mode), adding EC as RSA/DSA depreciated. I estimate there is a one man year at full time job in order to make OpenSC viable alternative to commercial products. I found that if we can reduce the number of reader framework OpenSC support it would be easier to support slot events (example). So why should OpenSC support OpenCT, CT, PC/SC? If there was a good reader framework we can reduce it to a single application API. I found out that bottom up approach may be needed, before fixing OpenSC maybe help to merge OpenCT and pcsc-lite.... I truly believe that a good reader framework will have great advantages. For example, convincing the projects that access the device directly to use a simple API, while providing other standard APIs (PC/SC, CT), the other technical stuff is also important (hotplug, driver simplicity etc). And here we are... I don't wish to let the option of having a free open source alternative in the cryptographic devices world die. If we don't provide good infrastructure we let this die. As Andreas said, OpenSC is in decline, and pcsc-lite project maintain only single CCID driver. Joining forces is the only way we can give this another chance. Every way we can make the implementation simpler and cleaner will help free future resources to deal with improving the offering. Just my thoughts.... Sorry if I bored you readers. > > But as a user I don't have a solution for mdev/udev only environment, > > pcscd waste my battery. > > And as a developer is too complex for me to contribute. > > Use libhal > Use libusb + IFD_GENERATE_HOTPLUG + udev > > I know we discussed this already. But I forgot why you can't use the > second solution? > > I quote one of your mails (24 April 2008): <snip> > Do you still have the same problem in the same configuration? I don't know, stopped using pcsc-lite and switched to openct. Made openct work as I expect from decent framework... It was simple enough for me to do this without any low level knowledge. The ifdhandler of openct just exit if device is removed (during suspend too), so no issue there. > Why do you use "pcscd with --force-reader-polling" in initramfs? > because udev events are not available at that time? There is no udev at that time, there is mdev. openct configuration works correctly with either. > > So as long as we have openct I prefer to use it. > > You can continue using OpenCT. No problem with that. Yes there is. It shows one test case of a user... There are many users. > A multi-slot CCID reader is one USB device (one CCID interface to > claim at the kernel level) used for two slots. I don't think you can > have two reader processes managing the same CCID interface. > You can have one process for two slots if you use (and plan to use) > asynchronous communications with the USB and the application. As I sent you in the interface specification, please read it... I tried hard to work quickly for you to see the interface I thought of. Each reader process will handle a single physical device, the model will support daemon/reader/slot enumeration. > I also know that someone is working on a composite USB device with two > different CCID readers inside. At the USB layer level it is only one > device so I guess you would get only one hotplug event. But you need > to start two (independent in this case) reader processes for this one > device. When it will be available I am sure we can address this new feature. > Isn't what pcscd is already doing? poll for new devices and start a > thread (instead of a process) per reader? Not exactly, if I recall correctly, it must have usbfs, and must be linked directly with libusb. I offered you in the past to separate the pcscd --hotplug trigger to external implementation so that it may be used separately. For example pcscd will not run if libhal library is not installed. > I know pcsc-lite is far from perfect and complex. But I do not want to > throw it away and start a new project. I think many problems can be > solved with (small) evolutions of pcsc-lite. > > Alon, if you can't help improve pcsc-lite with code because it is too > complex you can help me by describing use cases causing problems. Some cases: 1. pcscd is not stable during suspend/resume, I guess the root cause is not suspend but related to some other bug with thread handling, especially the way pcscd *KILLS* threads may cause issues. 2. pcscd still polls for card existence. Even after last CCID modification. This wastes performance and battery, review powertop output. OpenCT had shown that this is not required. OpenCT CCID implementation is fully event triggered. 3. pcscd runs as root, while not require it. 4. The IFD Handler API does not provide supportive reader environment. Although all is loaded into pcscd, the reader driver cannot access and resources to reduce its complexity. 5. Upstream does not support mdev/udev configurations. This means that simple configurations are not supported. 6. The configuration of hardware resides in pcscd, while correct practices imply placing this repository within the hotplug service. 7. Applications running during pcscd restart fail to continue running properly. Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
