On Wednesday 04 February 2009 11:11:26 Ludovic Rousseau wrote: > 2009/2/3 Alon Bar-Lev <[email protected]>: > > 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.
Again... For the 10th time... IFD handler API will be supported, but the maintained drivers will be encorage to switch into the new API as it would be easier to use, as unlike the IFD handler there is supportive environment (logging, protocols, device access etc). So I am not optimistic. I am realistic. I even agree to migrate your CCID into the new framework so you can continue maintain it without the need of doing the actual migration. > > 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. Got you. > > 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). I tried to help you out in the past and discovered the way you kill threads, which may cause the issue. If you want to fix it, you should install suspend/resume setup and reproduce this. But the above reply suggest you don't truly wish to fix this. > > 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. I hope so... The dependency of libusb forces you to compromise. See how clean the implementation of OpenCT is. > > 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. We discussed this too many times, Andreas also discussed this with you. OpenCT provide supportive environment for drivers, common code for logging, common code for protocols, common code for device access etc... If you write a driver using IFD Handler API you need to reinvent the wheel. > Maybe the solution you plan to use with your framework can also be > used for pcsc-lite without a complete rewrite. First, it won't b my framework but *our* framework. What you have: 1. PC/SC API - supported by you, nobody has any compliant. 2. CCID driver - supported by you, has the limitation of libusb and IFD Handler API. 3. Framework - threaded, complex, PC/SC specific which is what we discuss. What I wish is to replace the complex framework of pcsc-lite. It suggest rewrite of the PC/SC API to support the new framework. At first the CCID driver will continue working using the IFD Handler API supported by the new implementation, later on we will convert the CCID driver into native framework interface. What I suggest is for you to continue supporting and maintaining the PC/SC and CCID components, while I replace the mechanism that in the middle. > 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. Just to migrate from threaded to none threaded model is a complete rewrite. Moving the PC/SC API from the daemon to the client is a rewrite. I don't get how do you think you can provide a clean environment this way. I really don't. Alon. _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
