scd-backport-2-0 branch

[NIIBE Yutaka]

On 2012-06-25 at 11:32 +0200, Werner Koch wrote:
> On Mon, 25 Jun 2012 03:30, gniibe at fsij.org said:
> 
> > Currently, scdaemon keeps watching (and open and get status).  In the
> > use case above, a user doesn't expect scdaemon keeps watching for
> > insertion.  My concern is that this results shorter battery power life
> > for laptop.
> 
> You mean, we should replace polling by a proper method to do so.

There are two things: (1) Polling for "get status" for existing
token and (2) Polling for detecting insertion of token.

Let me talk about latter, at first.

My question here is: Is polling for detecting insertion needed?

The patch I sent yesterday is to show this issue (for token insertion.
The patch is not yet complete to handle card insertion, though).  Open
new connection will be done only by the thread of scd_command_handler
-> assuan_process (which I said "foreground").  After that, polling
will be done with "get status" for new connection.

With no polling of detecting insertion, status file will not be
updated immediately, script won't be executed immediately.  It will
only updated and executed after user will do some action to use token.
But, it seems for me that it's OK.

> > For the use case above, a patch like following makes sense.  The
> > scdaemon doesn't need to open by itself.  Once it will be open by
> > another foreground thread, it will get status, and keep watching to
> 
> What foreground thread do you have in mind?  A new one sleeping on
> USB events?

In the previous mail, I talked about to stop polling for detecting
insertion, and "foreground thread" meant the one of
scd_command_handler, which accepts request from gpg-agent.


Let's talk about (1) Polling for "get status".

> IIRC, it was not possible to do this with libusb or pcscd back when
> I wrote it.  On Linux we might find a way to sleep on reader
> changes; in general I prefer portable solutions, though.

There is no good general way other than polling to get status of
reader/token.

But, if CCID reader/token supports interrupt transfer for status, it
is possible to use this for it, instead of polling.  Now, newer libusb
(libusbx.org) has support for event driven asynchronous model, it is
possible to use single interrupt transfer URB.  I think that it is
portable, provided newer libusb is good enough for portability.

When CCID reader/token with interrupt transfer will be common, it will
be good to support this way, in future.

BTW, Gnuk does not (yet) support interrupt transfer.
--