persistent property store - first try

[David Zeuthen]

On Sat, 2004-06-12 at 21:33, Kay Sievers wrote:
> >  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?
> 

Yeah, that would make sense. Perhaps even putting the functionality of
HalPStore into HalDeviceStore and make the constructor accept NULL if we
don't need to write to disk (like for the temporary device store).

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

Yay, 'change' is a better name; naming is difficult :-). 

I think it makes sense to do this as well. Here's one example: maybe in
the future Linux will have driver binding and an OS vendor might want to
load a kernel module for a specific device based on information merged
from a .fdi file. Or something :-)

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

Everything with PERSISTENCE set for sure, initially we might want to tag
every attribute with this.

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

It's a real problem that some devices doesn't have serial numbers; we
should at least leave a TODO in the code that this is one possible
solution. Nice idea.

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

No, they're not, they may even be completely random at some point :-). 

Today, the tree for my CF Card Reader looks like this:

 usb_5dc_2_1_-1_noserial
  usb_5dc_2_1_-1_noserial_0
   scsi_host_6
    scsi_device_0_0_0_0
     block_8_0
      block_8_1

which isn't the same on reboot. Here's a possible solution:

 usb_5dc_2_1_-1_noserial
  usb_5dc_2_1_-1_noserial_0
   usb_5dc_2_1_-1_noserial_0_scsi_host
         (e.g. parent+"scsi_host")
    usb_5dc_2_1_-1_noserial_0_scsi_host_scsi_device_0
         (e.g. parent+"scsi_device_<lun_number>")
     usb_5dc_2_1_-1_noserial_0_scsi_host_scsi_device_0_block_top
         (e.g. parent+"block_top")
      usb_5dc_2_1_-1_noserial_0_scsi_host_scsi_device_0_block_part1
         (e.g. parent+"block_part<partition_number>")

For printers we might use some of the information obtained from
ioctl()'s in the UDI such that even Epson printers (which have same
vendorId/prodId) have good UDI's. 

In general I think a sane approach is to reuse the parent UDI and
concatenate unique and constant information.

> >  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/*' :)
> 

Heh, but we need to clean the home directories as well :-)

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

Yeah, that's one application for sure :-).

Cheers,
David



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