Andreas Jellinghaus wrote:
> openct already has a fci file, adding some
> information into it so gui tools can identify
> the result is not a bad idea I guess.
It's my plan to start with this file. This file uses "smart_card_reader"
for category. HAL specification recommends to use two FDI files in this
context.
information: Identify selected devices.
info.category = 'smart_card_reader'
info.capabilities = { 'openct' }
policy: Perform actions on these devices.
if capabilities contain 'openct' then add hald-addon-openct to
info.addons.
Example for disabling of openct for particular reader by (with a few
changes, pcsc-lite can be handled in a similar way):
<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<device>
<match key="info.subsystem" string="usb">
<match key="usb.vendor_id" int="0x0973">
<match key="usb.product_id" int="0x0001">
<remove key="info.capabilities" type="strlist">openct</remove>
</match>
</match>
</match>
</deviceinfo>
> so please use "smart card reader" and friends. or even better, throw
> in "iso 7816" somewhere, as that technical term is the best way to clearly
> say what we are talking about.
Good idea! But iso7816 could make it more cryptic to ordinary users.
I can imagine:
info.category = 'smart_card_reader'
info.capabilities = { 'openct', 'iso7816', 'smart_card_reader', 'usb_ccid' }
But we can introduce new keywords to not overload 'info.capabilities',
e. g. info.smart_card = { 'iso7816', 'usb_ccid' }
or even
info.smart_card.class = 3
I have no idea, what would be better in future.
> please don't use "card_reader", we already have trouble with people
> only knowing comptact flash / smart media cards / ... and being confused
> by what we call "smart card".
There are already CF/SM/... card readers, that support SIM cards as
well. That is why I can imagine 'card_reader.iso7816'.
> also I want to point out, that people might want to use smart card readers
> for authentication. hal seems to be very gui-desktop centric, if I'm not
> mistaken? (people still seem to use /etc/fstab to mount there filesystems,
> and not a hal config file....)
It is not GUI-centric, it is GUI-helpful. Tools for console users with
HAL exist as well.
The very simplistic example of HAL <-> GUI:
USB dongle inserted -> IRQ -> kernel (load driver) -> udev (create /dev
node) -> hal (scan partitions contents) -> dbus -> GUI is listening:
"Device /...udi was inserted. It has following partitions with following
file systems."
GUI thinks and says: "OK. Please mount with these options." -> dbus ->
hal (gets a mount request) -> mkdir & mount -> kernel
Work is done. User does not need root privileges, but can still control
mount process or even completely reject.
People with a static devices configuration don't need HAL.
> using udev was a huge pain for many years, everytime I thought "now it
> works", a few months later openct didn't work with the new udev. I'm sick
> of that pain, and since the udev/hotplug/linux-usb folks tell us to use hal,
> and hal seems to work, I think it is best to take their advice and do that:
> use hal!
I expect one another change in near future: Fedora people will say "Use
DeviceKit instead of hal."
> I have too little clue about the further developments of hal and policykit
> and what kde and gnome do, so I can't comment on that.
PolicyKit does not communicate with GNOME (with exception of local X
session registration). It only permits local access to ALSA and other
desktop centric devices.
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz
Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
