persistent property store - first try

[David Zeuthen]

On Wed, 2004-06-09 at 03:57, Kay Sievers wrote:
> Hi,

Hi,

Much sorry for the lag, been away from home again.

> here is a first try to store properties on disk. Please have a look, if
> we can do it this way. The properties are stored in a directory
> with the udi as the name. HAL creates a uuid starting with the hostname
> to be able to store user properies in a .hal/ directory home, so every box
> can have its own data in the users $HOME.
> 

Neat! I wanted to commit your latest patch that took Joe's comment into
account but ssh access to the fd.o box with the CVS repository is closed
down due to a SSH DoS.

Regarding integration into the current code this is probably good to
discuss; there's a few possibilities that are probably good to explore
on the mailing list. This fits nicely into other lifecycle issues of the
hal daemon, so good timing! The current lifecycle stuff is not exactly
good, cf. discussions on whether we should invoke callouts when hald
closes down.

> I've hooked it into the current code:
>   The saved properties are loaded after the device's fdi parsing.
>   The property are only saved if the key starts with "save". This is
>   just to be able to play around with it. We need to decide, which
>   properties we want to live on disk and when the save should be triggered.

Here's what I think hald should do

 1. When hald starts it claims the org.freedesktop.Hal service and emits
    a signal HaldBooting on the org.freedesktop.Hal.Manager interface.
    All requests to hald shall be rejected by casting an exception 
    org.freedesktop.Hal.ServiceNotAvailable for now.

 2. We load the last used device store from disk into a store named LDL
    (for Last Device List). If this is the first time hald runs, LDL is
    obviously empty.

 3. All buses are probed and presently rename_and_merge() from common.c
    is called for devices we add. Here we should check if the UDI is
    already in the LDL, if it is then copy the device from the LDL.
    We don't search for .fdi files if this is the case.
    Here's a question: we could do callouts here, but they shouldn't be
    'add', but maybe 'booting' instead? This is to let OS'es do some
    policy on a device every time the OS is booted. The other option
    is to do absolutely no callouts :-). In either case we should
    probably not emit D-BUS signals.

    Otherwise, it's a brand new device and we search for .fdi files and
    do the 'add callouts' and DeviceAdded D-BUS as usual. 

 4. Once all buses are probed do 'remove callouts' for the remaining
    devices in the LDL. Save the GDL to disk. Emit the HaldRunning
    on the Manager interface. Now we are running, we start servicing
    D-BUS requests again.

 5. Every time the GDL changes we update the files on disk. For
    properties that change a lot (though with the current scope we
    won't have any such) we can omit the use of HALD_PROP_ATTR_CALLOUT
    and HALD_PROP_ATTR_PERSISTENCE.

 6. When hald shuts down we emit the HaldShutdown signal on the Manager
    interface. All requests to hald shall be rejected by casting an
    exception org.freedesktop.Hal.ServiceNotAvailable.

 7. Again here we might do 'shutdown' callouts to let the OS do policy
    on every device when the OS shuts down.

 8. Save the GDL to disk (will be loaded as LDL when rebooting) one 
    final time. Release the org.freedesktop.Hal service. Exit.

A few things we need to take into consideration if we do it this way:

 a. We need to ensure that the UDI's are really as unique as can be.
    Presently this is the case for USB devices but we need to apply some
    minor tweaks to scsi, ide and block UDI computation. Should be
    rather trivial; we can always use the UDI of the parent and use
    some numbering scheme to ensure this.

 b. Using the disk should be configurable through the /etc/hald.conf
    file; we want to support hosts we a readonly filesystems.

 c. We probably want a tool to clear the device lists on disk :-)

 d. Some interface to rescan for .fdi files as one consequence of the
    plan above implies we only read .fdi the first time (which is nice
    as this may be time consuming).

Thoughts?

Many thanks,
David


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