persistent property store - first try

[Kay Sievers]

On Sat, 2004-06-12 at 20:30 +0200, David Zeuthen wrote:
> On Wed, 2004-06-09 at 03:57, Kay Sievers wrote:
> 
> Much sorry for the lag, been away from home again.

No problem, it was a nice and warm sunny day here, today :)

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

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

Nice idea to read the whole store in a new device_list. I thought we
call it for every device found, but this way we can use the merge logic.
We probably need a:
'HalDeviceStore *hal_pstore_load_store (HalPStore *pstore)' in pstore.c?

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

Sounds good. Callouts should be called, I think. We may need a user
trigger to reapply the .fdi files. So maybe we pass 'change' instead of
'booting' to the callouts?

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

What properties should go to disk? Should we search the gdl for the
PERSITENCE attributes? If we want to skip the .fdi search on a already
known device, we at least need the udi on the disk, right?

We may always save the topological position of the device to the pstore.
This way we have chance to find the right device if we have identical
ones connected at the same time. If the udi doesn't match exactly
(appended enumeration for identical devices), we may search for
unapplied devices in the pstore and merge if something is found with the
same topology.
Example:
I have two identical mice connected to a USB hub.
'usb_46d_c00e_1100_-1_noserial' and
'usb_46d_c00e_1100_-1_noserial-0'

If the first on is no longer present on reboot, the former '-0' one will
be recognized as the first one. If we check for the topology, we will
find the '-0' one and apply the right attributes. 

Hmm, does it sound crazy, or is it worth it?

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

Hmm, the current major/minor udi's for block devices is not stable
enough across reboot, right?

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

'rm -rf /var/hal/*' :)

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

Yes, right click with a context menu, on the device in
'hal-device-manager' sounds nice :)

thanks,
Kay


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