Plans for hal 0.5.x

[Joe Shaw]

[ Sorry for the late reply, for some reason this whole thread has
arrived in my mailbox out-of-order and 24 hours late.  sigh.  -j ]

On Sun, 2004-12-12 at 23:05 -0500, David Zeuthen wrote:
> 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).

This sounds like a good idea to me.  I'm not crazy about working around
broken drivers -- now that large distros with resources and expertise
ship HAL the onus should really be to fix the drivers -- I realize that
it's probably an unfortunate necessity to handle processes in diskwait.

I presume the interaction between the child programs and the daemon will
be done via dbus with some access control?

>  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).

Can you elaborate a little more on what you mean here?

>  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.

This seems to me to fit in with your first paragraph above.

>  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.

Ditto.

> 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.

We may want to keep a "compiled" on-disk database for this.  Maybe
sqlite or tdb or even berkeley db.  Otherwise I can see memory usage
getting a bit high especially after, for example, the enormous FDIs for
all the cameras libgphoto2 supports and sane's scanners.

>  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?)

FDI files probably make a lot more sense here now than a
callout-specific format like we talked about doing a long time ago.

I think ideally you'd want things to be based around the callout,
though.  Its FDI would define what device capabilities it cares about
and what device properties to be invoked for.  Unfortunately I'm not
sure how that kind of setup would be wedged into the device-centric
model.

> 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.

I'd ask that changes be as incremental as possible.  We should strive to
always keep CVS buildable and functional.  It's in no one's best
interest to land massive changes weeks apart.

Joe

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