Alon Bar-Lev wrote: > On 1/22/09, Stanislav Brabec <[email protected]> wrote: > > Alon Bar-Lev wrote:
> > > This is why you have udev, right? > > Yes, udev supports it as well. But most vendors prefer HAL for this > > purpose nowadays. > vendors? You mean Novell, right? Not only Novell. GNOME desktop use HAL and vendors providing GNOME provide hal as well. Even some mobile devices use HAL (Nokia N800/810, partially also Angstrom distribution). > > Using of HAL could bring several benefits: > > - splitting of "information" (e. g.: this USB device is a known Smart > > Card Reader, this /dev/ttyS0 is not a modem, but a Smart Card reader) > > and "policy" (is it a smart card reader => call pcscd --hotplug). > > OK... Don't see benefit here except of some better Windows like device > manager. > But except of presenting it to the user, what should the user do with > the information? The main benefit: Search for devices by capabilities, not by bus where they are attached. This information may be used in any application. Several programs use HAL to show/hide systray applet, depending on device presence (Bluetooth, UPS), start user space utilities to manage particular devices etc. As none of these actions need root access, it may be easily configured. New Xorg uses HAL to detect available input devices. > For USB it is easy, no need to change anything in pcscd and openct. Definitely, it's easy. Just only several fdi files telling something about devices, no change in pcscd or openct (however libhal interface may be modified a bit to maintain device IDs just once.) > > - HAL can support non-trivial probers, that can identify devices more > > exactly than udev can do (e. g. which device hangs on serial port, > > scan for partitions) > > Nothing relevant here. Serial prober can support smart cards. Even without it, creating a special static file would generate smart_card_reader device event for /dev/ttyS1. > > - GUI device viewers can correctly identify device type > > Great! > But GUI can be separate. Complete separation of GUI and hardware is one of purposes of HAL. > > - Applications can easily implement device list change event listening, > > even without root access. > > This can be done via the reader frameworks... pcsc/openct. Yes, but HAL is more flexible. One code can handle autologin via smart cards and dumb USB memory cards. > > There are also cons: > > - HAL is not so straight forward as udev. > > This is why I don't use it. Just takes CPU and other resources. > No way to configure it easily. A bit harder to configure, but more flexible. With udev, device match and action has to be specified at once. With udev you don't have any chance to implement negative match (e. g. This /dev/ttyS1 is not modem, but Smart Card reader. Don't allow GID modem writability to it. > > - In future it will be probably replaced by DeviceKit. > > Oh... So hal failed. Why invest more? Not completely. The idea of device infrastructure will remain there, only implementation will change. DeviceKit, DeviceKit-discs, DeviceKit-power and udev-extra packages are intended as successors of HAL. But the implementation is not yet ready. > > My current intention was: > > - Define HAL standard keywords for smart card readers (and maybe for > > their features). > > - Identify all Smart Cards by HAL. > > Smartcards or readers? > I guess you mean smartcard. Sorry, I meant devices = Readers. Smart card insertion detection is possible as well, but not in my plan. > > - Define access policy > > Only pcscd/openct can access. > openct already uses udev in order to do this, nothing else is needed. > pcscd cannot run as none root... In an ideal world, where all applications use pcscd. > > - And finally move pcscd hotplug from udev to hal. With a bit of > > configuration, it may support serial port readers. > > I think it is already implemented using hal. One of the reasons why I > turned to openct. My mistake. pcscd can now use hal directly. But if you don't like it, you can revert to udev helper. > Adding hal dependency to these components is not wise. It makes > command-line only and server installation must more difficult. > Low level devices should be handled by udev. > Hal is great for devices that should be managed by users (removable > media, cameras). The dependency on hal already exists there, but you can compile without its support. HAL is only a device enumeration service. If you can live with static device configuration, most applications can exist without HAL. HAL needs about 1.2 MB of RAM. Command line utilities supporting hal exists as well (mounting of devices with user permission, device access control while logging to physical console etc.) > > One of example features, that can be easily implemented in Display > > Manager with HAL: > > > > Smart card token is just plugged => read it, auto-login user > > And if the user already logged on? It's above the scope of HAL. and depends on implementation. (If the used is already logged, pam_pkcs11 will probably unlock the screensaver). > In which desktop will it run? I have seen smart card auto-login feature request for GDM (GNOME). I guess that somebody will want to implement it. > How will it request passphrase? pam_pkcs11 already supports it. > > Smart card token is just unplugged => save and kill the session, logout > > And if you have two plugged in? It's above the scope of HAL. HAL does only enumeration of devices. (But if you are asking for my opinion: Application should probably disable login for this token and send policy violation alert: User JohnDoe left and forgot token in the machine.) > The pam_pkcs11 has a simple process that takes care of this without > any complex configurations. pam_pkcs11 is a login part. For forced logout/lock part, you need to watch for token removal in the session manager or screensaver. You can use pcscd (and support this feature with Smart Cards only) or HAL (and support this feature with any device type - e. g. the same code can force logout/lock using Bluetooth proximity watch). > Polling is bad. I just added support for openct to stop polling. > Modern applications should not poll. When the device sends sends status change signals without polling, then polling is not required. USB peripheral cannot initiate transfer, so USB requires some type of polling by design. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: [email protected] 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 [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
