Support event mode for drivers
Current implementation forces poll loop every one second or so,
this consume CPU and power.
This changeset adds the ability for a driver to provide file
descriptor for event handling, removing the need to poll.
Only the CCID USB driver was modified to use this new interface.
One issue... I had to reset USB device after first communication,
I don't believe it is something relates to what I've done.
Only Linux USB interface was modifid to use this new interface.
All other drivers/environments should fallback into the poll mode.
New driver methods:
before_command
Executed before command, makes it easy to remove event capture.
after_command
Execute after command, makes it easy to add event capture.
get_eventfd
Get an event fd out of the driver, if unsupported -1 should
be returned, this fallback into the poll mode.
event
Event method to call with th evntfd is signaled.
New USB methods:
ifd_usb_get_eventfd
Get event fd to poll for events.
ifd_usb_capture_event
None blocking capture.
Available at branch [1].
Please check it out.
Chaskiel, please look at the ccid_open_usb(), and try to help me
figure out why I had to add ifd_sysdep_usb_reset() in order to make
the reader respond to the initial status query.
Another improvement I thought about is to power off the card if it is
unlocked after a period of time.
Alon.
[1]
https://www.opensc-project.org/svn/openct/branches/alonbl/usb-ccid-reduce-busy
On 12/21/08, Alon Bar-Lev <alon.bar...@gmail.com> wrote:
> Thanks Andreas,
>
> Thank you for your comment.
> I am for dropping old kernels hacks... And provide better solution for users.
> I now understand why mainloop wakes up...
> i will try to implement something.
>
>
> Alon.
>
>
> On 12/21/08, Andreas Jellinghaus <a...@dungeon.inka.de> wrote:
> > in usb apps you can't poll a usb file handle without timeout -
> > older kernels have a bug, where device removed event is not
> > handled when it happends, but the application is only notified
> > after the timeout is over. if that is 0, the applications waits
> > forever.
> >
> > thats why we had a loop with 1 second or so in the openct pre-decessor.
> > hmm, not 100% sure how openct works in that regards. but we can change
> > the code, I think kernels with this bug are no longer relevant / we
> > can expect kernels to be fixed now.
> >
> > also we could optimize those loops - make sure if nothing happends, that
> > nothing is written to the syslog (unless someone has a very high debug
> > option). but I guess the code is already ok.
> >
> > when it comes to the individual drivers: sorry, I have no clue about them
> > other than the very simple etoken driver and friends.
> >
> > Regards, Andreas
> >
> >
>
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
