Hello, 2009/2/2 Alon Bar-Lev <alon.bar...@gmail.com>: > On Monday 02 February 2009 21:58:17 Andreas Jellinghaus wrote: >> but today pcsc-lite is active maintained by ludovic, has a huge amount of >> features, and works well. I wonder why anyone would want to spend a huge >> amount of time to get similar features ported to / written for openct or some >> new design. but this is open source, we don't stop anyone from writing new >> code, competition is good. so if alon wants to explore new ideas, let him, >> why not? > > One of my main goals was to work *WITH* Ludovic in order to separate the > PC/SC API from the reader infrastructure, allowing much more simpler > implementation of the reader part. > > I always wrote that I won't create another competing project, if Ludovic > don't see any advantage I drop the idea.
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. > 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): > Managed to reproduce this, and strace of pcscd just waits in select... > I cannot see who/what writing this message. > > Anyway, I think that I did not explain my installation correctly... :) > > My initramfs does the following: > 1. Start pcscd with --force-reader-polling > 2. I use opensc-pkcs11.so to extract some data object. > 3. The data is used in order to decrypt the harddisk. > > Boot: > 1. Initramfs stuff. > 2. Start pcscd using udev events. > > Resume: > 1. Initramfs stuff. > > Notice that on resume you have two pcscd instances running in > parallel, the suspended pcscd which is unaware of the other activity. > And the one which is used to extract encryption keys. > > Until now I used different PKCS#11 provider which uses pcscd, it > worked 98% of the time, as the other PKCS#11 provider work stateless. > > Can you please help me in fixing this? Do you still have the same problem in the same configuration? Why do you use "pcscd with --force-reader-polling" in initramfs? because udev events are not available at that time? > So as long as we have openct I prefer to use it. You can continue using OpenCT. No problem with that. My problem is with normal users and issues they have when openct and pcsc-lite are both installed. >> but - reality check - one feature of the new code would be thread-less, >> right? >> I'm not sure you can implement multi-slot readers without threads (or if you >> can: wouldn't that have about the same complexity)? > > No. You have a file descriptor of usb and poll it. > You can also handle several readers... You have two file descriptors and > poll them... > Nothing fancy. > Simple and working. > It is like you suggest that implementing a web server requires threads... > While having more threads than the number of CPUs actually wastes > resources. 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. 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. >> also I believe pcsc-lite works on many old and exotic systems. for example >> "hotplug service" is something we have on linux. but older unixes, bsd >> systems, embedded systems? I'm not too sure here. in fact I used to be happy >> about the linux hotlug stuff starting in 2003, and all these years it was a >> pain for me to get openct to work on non-linux. maybe the situation has >> improved a lot meanwhile, I don't know. > > This is also not a problem, as I suggested long ago to Ludovic regarding > pcscd in > initramfs environment, it is easy to implement libusb enabled daemon that > polls > for new devices and forks the reader daemon. Isn't what pcscd is already doing? poll for new devices and start a thread (instead of a process) per reader? 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. Bye -- Dr. Ludovic Rousseau _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
