--On Thursday, January 22, 2009 06:50:34 PM +0100 Andreas Jellinghaus <a...@dungeon.inka.de> wrote:
> more complex operations such as "upload new firmware > to card reader" will most propably never work with pcscd (guessing only, > I'm no expert here). I think that's going to depend on the reader driver. There certainly is a reader-level IFDHControl operation which could do pretty much arbitrary operations. Of course, such operations are likely to require close cooperation between the reader and application. OTOH, I don't think you want non-privileged users uploading new firmware to devices anyway. > my personal recommendation is: > * use libccid + pcsc-lite for all smart card readers and applications Well, all CCID readers, anyway. Obviously you need a different driver for non-CCID readers. > * yes, that means not using openct. we need to admit, that openct > has no proper pin entry code for readers with display and pinpad. Or openct could be improved in this area. Currently my preference is to continue using pcsc-lite, but as you can tell from the discussion Alon and I have been having, there are definitely tradeoffs involved. > * yes, that also means not using the (most likely binary only?) code > the vendor published. I'm pro open source here, sure. also I think > distributions are much better off with one generic software, than > they are with many vendor-specific incompatible solutions. I'm pro-open-source, too, but not to the exclusion of people being able to get work done. Open source is a means to an end, not an end in itself, and too often its advocates forget that. > 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? Not really. HAL is an abstraction for device enumeration. It's not GUI-desktop-centric at all, but many of its current users are. > (people still seem to use /etc/fstab to mount there filesystems, > and not a hal config file....) That's because most people aren't insane, and other than for certain special cases (mostly, removable media), HAL doesn't offer any improvement in this area over the existing model. > 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! udev went through a lot of growing pains. I think that's been over for a while, but I haven't been watching closely, so I may be wrong. I'm perfectly happy to use HAL in situations where it's appropriate, but I agree with Alon that HAL is not appropriate for every situation. Particularly, it's unneeded complexity in embedded environments where there are a small number of possible hardware configurations and they don't change much. -- Jeff _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
