2011/3/18 Martin Preuss <[email protected]>:
> Hi,
>
> On Freitag 18 März 2011, Ludovic Rousseau wrote:
> [...]
>> As written in the specification:
>> " If the driver does not understand the :libusb: or :libhal: scheme or
>> if a new scheme is used, the driver should ignore the part it does not
>> understand instead of failing. "
> [...]
>
> Yeah right... But the driver can't just ignore what it doesn't understand
> because in that case the driver has no way of determining which reader pcscd
> exactly meant.
>
> Your specs might work well if only one reader is installed, but how should the
> driver determine which reader the daemon meant if it can't derive that
> information from the device name?

Exact. I introduced IFDHCreateChannelByName() exactly to solve the 2
or more identical readers issue.

It is up to you to decide if your driver should always fail if it does
not understand a naming scheme or have some problem when 2 identical
readers are connected at the exact same time.

My CCID driver does not fully support the libhal: scheme, and does not
yet support the libudev: scheme. But does not fail. It just ignore the
part it can't parse.

> The driver could of course manage its own list of currently active readers,
> but I really believe this is the job of the resource manager. And if the
> resource manager introduces new ways of naming devices it should at least
> provide a fallback for existing drivers, which the current pcscd does. And for
> this to work the pcscd needs some kind of feedback from the driver which tells
> it to try another naming scheme. That's only possible by returning an error
> code.

I agree.

The online documentation was not up to date. pcsc-lite 1.7.0 do not
use libhal but libudev. So pcscd now uses the libudev: naming scheme.
The name is something like
"usb:08e6/3437:libudev:0:/dev/bus/usb/008/047"

And hotplug_libudev.c does not (yet) fallback to the libusb: scheme if
the driver fails with the libudev: one.
It looks it is something I will have to implement or your driver will
always fail again.


> At any rate, the way your daemon works nowadays is the best possible solution
> so I consider this matter closed.

Except that the introduction of libudev broke the solution working for you :-}
I will try to fix it in version 1.7.1. You can also submit a patch to help.

Bye,

-- 
 Dr. Ludovic Rousseau

_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle

Reply via email to