Plans for hal 0.5.x
david at fubar.dk
Mon Dec 13 17:23:16 PST 2004
On Mon, 2004-12-13 at 18:54 -0500, Joe Shaw wrote:
> [ 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.
Yeah, well, today hald can basically lock up. With the Linux kernel
being sort of a moving target, I'd rather play on the safe side.
> I presume the interaction between the child programs and the daemon will
> be done via dbus with some access control?
The plan I had in mind was basically that child programs use libhal -
this means that this interface needs to be expanded a bit more. For
example, the poller for optical, floppy and IDE zip drives will need to
add/remove child device objects when media is detected in the drive.
Nothing earth shattering though.
Access control would then be handled through standard D-BUS interfaces
(e.g. only allow haldaemon/root users to call juicy methods).
> > 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?
Basically, to determine if the calling process (identified by uid and
pid) invoking a D-BUS method is authorized to do so.
This is not a so big deal today, but for planned high-level operations
such as Eject() on the org.freedesktop.Hal.Device.Block interface or
Setup() on the org.freedesktop.Hal.Device.Block.Crypto (see my mail on
encrypted storage), I imagine distributions are interested in not
letting every random user invoke these. There are other examples of
methods it makes sense to expose. Ideally, such policy should be
expressed in D-BUS but no-one have did this in a distribution
independent fashion yet .
For Fedora, I will probably initially use pam_console to only let
authorized users at the console perform such operations. It would make
sense to have a standard auth system to express e.g. that
only /usr/bin/nautilus invoked by an authorized console user may invoke
method Foo() on interface Bar.
I'm not planning to spend a lot of time on this though; the
implementation for Fedora will just be using pam_console.
Stuff like that, basically.
 : There is the at_console policy piece in D-BUS but that is
pam_console/Red Hat specific - not very nice.
> > 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.
Yes. I also want to do some benchmarking of .fdi files, it doesn't look
to bad though - computers are fast nowadays.
I also though about splitting the parser out so anyone can use it -
ideally .fdi files could be used in other areas; e.g. you could define
your desktop policy around .fdi files (e.g. launch flumotion when a
webcam have been inserted, implement g-v-m functionality, popup
notifications) - just a thought (probably not a good idea, .fdi files
are meant to be declarative)
> > 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.
Yes, I think so too. It requires some kind of list datatype to stuff
binaries on to.
> 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
Yes, the actual callout would install the .fdi file. Callouts when
property changes are probably not too useful; one would install an addon
that listens using libhal to handle that.
> > 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.
That makes sense. My initial idea was to start a new daemon/ directory
and copy changes over but I'm more and more leaning on just hacking on
the existing bits. Some changes are going to be a bit massive though,
Kay's udevd work really makes things a lot easier to deal with. I'll
keep it buildable though.
hal mailing list
hal at lists.freedesktop.org
More information about the Hal