On 2/3/09, Ludovic Rousseau <ludovic.rouss...@gmail.com> wrote: > 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 >
-- Sent from my mobile device Martin Paljak mar...@paljak.pri.ee http://martin.paljak.pri.ee GSM:+3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
