2009/2/3 Alon Bar-Lev <alon.bar...@gmail.com>: > 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 think you are too optimistic here. Many drivers will not migrate because they are not maintained: "dead" upstream for free software drivers, or no "resources" for proprietary drivers. > 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. Yes, but I do not have enough free time. >> 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. pcscd uses libusb (which uses usbfs or something else) if configured to use libusb. If you use libhal then libusb is not used. > 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. I do not use suspend/resume myself. If you can describe the problem precisely I can have a look at it. Or provide a way for me to easily reproduce it (without a real suspend/resume). > 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. If your CCID reader does support RDR_to_PC_NotifySlotChange then pcscd should not polls for card existence. Because of problems with libusb I have to timeout every 2 seconds so a PC_to_RDR_GetSlotStatus command is sent to the reader every 2 seconds. This short timeout should be removed in a later version of the CCID driver. > 3. pcscd runs as root, while not require it. Point 6 on the pcsc-lite TODO list. > 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. I don't see what you want here. > 5. Upstream does not support mdev/udev configurations. This means that simple > configurations are not supported. mdev/udev is a driver property. A driver configuration file should just call "pcscd --hotplug" when a reader is inserted or removed. My CCID driver provides a src/pcscd_ccid.rules file for that. Maybe it can be improved. Patches welcome. > 6. The configuration of hardware resides in pcscd, while correct practices > imply > placing this repository within the hotplug service. It all depends how to manage hotplug. With the work done by Stanislav Brabec to generate a "smart_card_reader" HAL event we can remove the configuration from pcscd. > 7. Applications running during pcscd restart fail to continue running > properly. Maybe the solution you plan to use with your framework can also be used for pcsc-lite without a complete rewrite. I imagine you need to restart pcscd when yo switch from initramfs to the real filesystem. Why can't you call SCardEstablishContext() to get a context with the new pcscd? Alon, you have issues with pcsc-lite and I agree on most of them. But I think they can be addressed one after the other in pcsc-lite without a complete rewrite. Regards, -- Dr. Ludovic Rousseau _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
