Plans for hal 0.5.x

[David Zeuthen]

Hi,

With the 0.4.x stable series actually stabilizing (will release 0.4.3
fairly soon, need to fix one more bug[1]), I think it would be good to
discuss what to work on now. We've kind of discussed, so some of this is
just reiterating those issues. There is new stuff also.

So, while I do think the current architecture is pretty nice, e.g. hal
device objects with typed properties, D-BUS interfaces + notifications,
device information files, callouts and so forth, it's less than ideal to
have everything in a single process. This is both from a from a
stability, security and extension point of view

Regarding the stability issues, I've seen usb-storage lock up and put
hald in state D (uninterruptible sleep) for good too often; while kernel
drivers may improve I think all access to device files (fs detection,
polling, printer identification, etc.) should be taken care of by
programs exec'ed by hald - we may just ignore them if they time out
(e.g. the child enters the state D for good). This will ensure that the
hald process never ever locks up (on that account at least).

New features I want to put in the hal framework:

 1) Would be nice to have a list datatype

 2) Some centralized management of whether a caller is allowed to invoke
    this or that method so it's easier for vendors to patch hal to work
    with their auth system (on Red Hat, I would probably use
    pam_console).

 3) Would be nice to map methods on arbitrary D-BUS interfaces for hal
    device objects to binaries. See my earlier mail today on encryption
    ideas. Can be used for a boatload of other stuff; e.g.
    SetLCDBrightness().

 4) Addons; make it easy to write and integrate e.g. the battery polling
    software that Sergey is working on; ideally what we today have for 
    polling a USB or CD-ROM drive would be such an addon.

 5) Persistent properties; want to make this a whole lot simpler.
    Basically just a new hal_property_is_persistent(const char *key,
    bool_t is_persistent) and some management around that (e.g. track-
    by-connection if we know the UDI is not unique). 

These are the new device types I'd like to add support for

 1) cameras; we already support these, but I'd really like to kill of
    hal_hotplug_map and get the list of cameras as one gigantic .fdi
    file - ideally the gphoto2 package would install that .fdi file
    on the system.

 2) scanners; should be a simple job of writing .fdi files; same story
    as for cameras; get the .fdi file form the SANE package.

 3) PDA; David Malcolm worked on this; time to merge his changes

 4) ACPI/PMU: Should be a job of reading off files in /proc or using
    /dev/pmu. Sergey already did the spec of what the properties should
    look like; we should just use that. Also add support for laptop-
    specific interfaces through hal framework ideas 3) and 4) above.

 5) USB-HID-based UPS'es - I actually went out and bought a UPS because
    I got excited about the work by Sergey - it's pretty easy to support
    since it speaks the USB-HID protocol. Again this is just to be built
    as another add-on.

Things I want to fix, for optimization purposes:

 1) we parse all .fdi files on every new device object. Ideally we
    should read all of them on startup and cache the rules in memory.

 2) there should be a way to control what to callout instead of invoking
    out all the callouts for each and every new device object; ideally
    this should be tagged through .fdi files (e.g. info.callouts which
    is a list of binaries to invoke?)

Other thoughts about what could be productive to do in the Making
Hardware Just Work(tm) world, but is not strictly part of hal, is in
[2].

I also want to generally clean up the code as it's more or less a bit
messy right now; this is partly due to the great improvements in linux-
hotplug and udev by Kay Sievers (with that, a lot less things needs to
be asynchronous in hal) and partly due to the mixture of D-BUS/glib/libc
datatypes used throughout the code (we didn't initially used glib!). It
needs an audit as well (though most interfaces are to trusted sources).
The libhal interface will have minor changes as well, but I think we can
keep backwards compat.

Ideally, we should be able to support things like systems with many
thousands of disks, I don't think we do that in a graceful way today; I
could be wrong though, I don't have such a system. I think it's
something we should do though.

So, this is also a heads up that things are going to change in HEAD; I'm
planning to refactor/rewrite most of the code, but note that it's an
explicit goal to not change too many interfaces.  It's basically just a
cleanup of the code, such that the code is as nice as the architecture.

My target for finishing this work is around mid-to-late-February, which
may be a bit ambitious but I'm planning to work full time on it. I will
probably not release 0.5.0 before sometime in January.

Thoughts?

Cheers,
David

[1] : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142183

[2] : 

 1) I actually think it would be nice to have a hal-aware mount wrapper
    shipped with the hal package. This could read properties from the
    desktop sessions preferences system (e.g. gconf) to see if something
    should be mounted sync/async. Could also interact with the session
    and say "I need the root password to mount read/write" for e.g.
    hotpluggable devices. See this rant
    http://www.pbs.org/cringely/pulpit/pulpit20040916.html
    and ponder about the sections concerning Epoxy glue :-). We would
    use the storage.policy.* namespace for this.
    Such a wrapper would ideally be split up into GNOME, KDE, whatever
    frontends (the GNOME version would read from gconf and use GTK+
    for dialogs). The wrapper would also use libhal-storage.

 2) Finish the gnome-vfs patch (see utopia-list at gnome.org) to a) make
    the one-to-many patch work and b) show icons for all drives even
    though they don't have media in them. Also make it not rely on the
    fstab-sync program.

 3) Make Nautilus use libhal and libhal-storage to populate the context
    menu - for portable_music_player's we would have e.g. "Open
    Rhythmbox", and for cameras we would have e.g. "Open F-Spot" as the
    default action.

 4) Make gnome-vfs capable of using libgphoto with URI's
    gphoto2:///001/043 (for USB device 43 on USB bus 1). Make hal make
    that URI available in computer:/// when we see a libghoto2 supported
    camera.


_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal