2009/1/23 Stanislav Brabec <sbra...@suse.cz>:
> Andreas Jellinghaus píše v Pá 23. 01. 2009 v 13:27 +0100:
>> Am Freitag 23 Januar 2009 12:59:57 schrieb Stanislav Brabec:
>> > HAL documentation recommends to discriminate between three types of FDI
>> > files:
>> > - preprobe: Actions before hal starts to identify the device
>> > - information: Collecting information about the device
>> > - policy: Perform actions
>> >
>> > Current openct FDI file mixes information (that it is a Smart Card
>> > reader) and policy (call hal addon).
>> >
>> > One of possible ways to implement it better is an additional keyword.
>> > Another way would be using of USB IDs known as Smart Card readers in
>> > information and repeating USB IDs of readers known to work in policy.
>>
>> ah, good point. cleaning this up is a good idea.
>
> Well, maybe "capabilities" is not a right place to add this keyword, but
> the idea remains.
>
>> with hal, do we need to make sure only either openct fdi file or ccid fdi
>> file is installed? or how can you manage, whether some device will be
>> used by openct or by libccid+pcsc-lite?
>
> No. With "append" keyword, values from both are joined. But actually
> only openct needs FDI file for HAL hotplugging. pcsc-lite evaluates
> devices on its own.

If I want to run pcscd as non-root (in a future version) I will also
need FDI files (to solve the same problem as openct: change the access
rights of the smart card reader device).

> A separately maintained package would be another possible way to
> distribute FDI files: Scan all available driver packages, create a list
> of all known readers, their USB/PCI ids and capabilities (class, card
> format,...).

I was thinking of generating the FDI file(s) dynamically. pcsc-lite
knows all the vendorID and productID of the USB devices it supports
thanks to the Info.plist of each driver.

The best place to place an FDI would be in the driver package. The
driver knows which USB device it can manage. But to be backward
compatible the solution should work without changing every driver
package (binary and source code).

> Whether device will be used by openct:
>
> The dedicated keyword described above will introduce call of
> hald-addon-openct in the "policy" phase. Manipulation with this keyword
> can be done with third party FDI files (see XML example sent yesterday).
>
> Whether device will be used by pcsc-lite:
>
> pcsc-lite listens to all hotplug events. In theory, it may listen only
> to events containing smart_card_reader capability and even move driver
> detection to HAL. But I don't think, that it is a good idea. pcsc-lite
> has its own platform-independent standard way to do it.

Once the FDI files are in place pcscd could just listen to events
containing smart_card_reader capability.

I guess that having two FDI files (one form OpenCT and one from
pcsc-lite) for the same USB device and doing the same action is not a
problem?
OpenCT and pcsc-lite do not work well together since they both (want
to) claim the device.

Bye

PS: I am new to HAL and the FDI files :-)

-- 
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to