On 12/19/08, Chaskiel M Grundman <c...@andrew.cmu.edu> wrote: > > I thought to make the blocking poll() at ct_mainloop() > > The only reason ct_mainloop calls ifdhandler_poll_presence is so that the > status file is updated. If we don't care about the status file anymore, > then ct_mainloop doesn't need to know if there's a card inserted or not.
But we need somewho to provide notification in the API in stead, right? > > call a new > > method that may return event file descriptor from the reader driver > > The only way I'd be able to provide a file descriptor with the behavior I > think you want (becomes readable to poll() when the card status changes) > is to have a thread polling the device as it does now (but possibly with > much longer usb timeouts). How is pushing this work into each ifd helpful? Oh... I want to avoid theads if possible. I thought of polling the client socket and usb fds, so I exit the poll if I got a command or something was sent from the reader. Wouldn't this work? > In any case, the ccid feature doesn't actually help you achieve this goal, > so I'll stop participating in this discussion unless you'd prefer me to > keep paying attention. Once you have an architecture, I will probably help > adapt the ccid ifd to work with it. Right. I should have modified the subject... I just recalled that Antii suggested to help modifying the infrastructure to use sockets. Thanks! Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
