persistent property store - first try
david at fubar.dk
Sat Jun 12 11:30:11 PDT 2004
On Wed, 2004-06-09 at 03:57, Kay Sievers wrote:
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
> 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
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
6. When hald shuts down we emit the HaldShutdown signal on the Manager
interface. All requests to hald shall be rejected by casting an
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).
hal mailing list
hal at freedesktop.org
More information about the Hal