On 1/23/09, Andreas Jellinghaus <a...@dungeon.inka.de> wrote: > > 3. pcscd must run as root... A none root mode may be supported but > > never implemented. > forgive me, but usb control transfer ioctl can only be done as root I thought? > thus anyone trying these on a usb device needs root? or is write access to > the device enough?
No... mdev/udev/hal can set permission on the device so that the daemon can access it using none root account. Look at recent openct. > > 4. Due to the threading limitation of libusb or kenrel pcscd polls > > readers every 2 seconds which waste CPU and power resources. > the kernel had a bug not dealing with properly disconnected usb > devices, thus they have to - and openct does (did?) the samething. No... this is not the case. There is an issue with libusb and threading or whatever. Nothing relevant to coldplug. See Ludovic description [1][2]. [1] http://www.nabble.com/event-handling-and-canceled-thread-issue-(again)-to20794059.html [2] http://thread.gmane.org/gmane.comp.lib.libusb.devel.general/4444 > > 5. The udev support was dropped in favor of hal, which added > > dependency for all scenarios. > > openct users are often confused by the many choices they have. > not sure it is such a bad thing to reduce the number of supported > options. Yes it is, if you add new dependencies. Which are not *MUST* have. > > 6. The libusb support polls the USB bus... So it is irrelevant. > > well, if you aim to support non-linux, watching the usb bus yourself > seems to be the best or only option you have to notice new devices > etc. also watching usb is much simpler than the hotplug/udev/hal > maze which needed many changes over the years. openct does coldplug in many OSes without libusb... You don't need to watch... The main problem is the coldplug. Anyway... Worse scenario... You can always ask hal to enumerate devices for you :) > > While openct... > > 1. Much simpler. > > but it cannot match the features pcscd has, does not even come close. True. This why I suggest we work together in order to combin the best of these two solutions. Take the 1 process per reader feature and simplicity of openct. Take the pcsc API which can be a simple library (No need for pcscd). Make the pcsc API communicate with the reader processes via sockets. Allow also openct API to communicate with the same processes. Or any other implementation. We do not need two competing projects.... Separating between the device management and the API exposed to applications, simplify the code to handle readers, and allow reuse of drivers in many types of applications will enable us to focus resources on improving the features to users. > > 4. Does not use hal or libusb. > > hu? how does openct implement coldplugging these days? > that code always depended on libusb. Only for Linux.... and as I don't have usbfs on my system I removed this as well. > > 6. At least ccid and etoken drivers does not poll devices. > what about the core, how do we detect if a driver was unplugged? Using signal from the kernel. Without usbfs feature of kernel there was a bug I found, it will be available (hopefully) in the next stable 2.6.28. Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
