On Mon, Feb 2, 2009 at 8:02 PM, Jeffrey Hutzelman <[email protected]> wrote: > The way to do this is to have a single service which provides a rendesvous > point for clients and readers, keeps track of what readers exist and of > their state, informs clients of changes they are interested in, and mediates > when more than one client wishes to access the same reader. > > This is more reliable than depending on communicating via a filesystem whose > state does not automatically change in exceptional circumstances such as > when a reader process exits, more portable than depending on inotify, and > more efficient than including copies of the server and mediation code in > every reader driver and copies of the reader enumeration, selection, and > monitoring code in every client application.
Yes. On system without filesystem events this is valid option. Worse case scenario... Have /var/run/libreader/event directory. Each client can register pipe there. When event happens in reader process write single byte to each pipe. The problem... User has privilege to write to a directory outside his home, I don't like this as well. But... Look at two implementations: pcscd and openct. pcscd works exactly as you describe, one daemon which handles all readers. openct works in process per reader without central daemon. Experience had shown that pcscd is much more complex to maitain than openct, for both reader driver part and application part. What I want is to take the best of the two projects and create a single one. pcscd is complex multithreaded daemon, difficult to integrate with hotplug services (mdev, udev), has advantage in its API exposes to applications, has the most usable CCID driver. It forces a dependency between PC/SC API and reader access. openct is simple single threaded multiple process, simple to integrate with hotplug services, has a very simple application interface based on CTAPI, has very simple driver interace, but lacks event driven application interface. So basically what I want to create is: 1. Simple model for reader drivers, similar to openct model. 2. A generic none blocking event driven client library. 3. Implementation of PC/SC above the client library. 4. [optional] Implementation of CTAPI above the client library. 5. Conversion of IFD CCID driver to the new framework, so it will be much more efficient and an example. 6. Convert some of openct drivers into the new framework. 7. I hope that projects that used direct reader access be able to use the reader library. Alon. _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
