persistent device storage

[David Zeuthen]

On Sun, 2004-05-09 at 19:54 +0200, Kay Sievers wrote:
> I have a few questions about the persistence device store:
> 

Yay!

> db-key:
> The udi is always the key to the device? And should it also be for the
> persistent store?
> 

Yep, udi seems like a good choice.

> db-format:
> What about a simple file/directory database with one value per file,
> (like sysfs)?
> 
> /var/lib/hal/devices/
> |-- usb_4a9_3056_1_-1_noserial
> |   |-- info
> |   |   |-- product
> |   |   |-- capabilities
> |   |   `-- persistent
> |   `-- linux
> |       `-- sysfs_path
> |-- usb_46d_c00e_1100_-1_noserial
> |   |-- info
> |       |-- product
> |       |-- capabilities
> |       `-- category
> |...
> 

This seems like a good idea; perhaps the properties need not to be put
in subdirectories e.g. we could have just

 /var/lib/hal/devices/usb_4a9_3056_1-1_noserial/info.product

Should the files be human readable? Currently we support int32, bool,
double, string and in the future I envision it might be useful to also
support int64 and blob.

> db-content:
> Which properties should go into the store? hald needs to scan every
> device on startup, even if the properties are already stored. So should
> a property have a "persistent" attribute or should all current
> properties go into the store?
> 

I think all properties should be saved; before Robert did the callouts
for property changed I had some idea that hal could provide e.g.
properties net.tx and net.rx that is updated several times a second. But
this would cause a storm of DBUS messages and fork/exec so the currently
policy is only to include properties that doesn't change a lot.

Also note that hal already has a concept of a persistent device; that's
when info.persistent==TRUE and it means that the HalDevice object will
not go away once the device is removed. This is useful for when storing
properties on devices, e.g. Konqueror or Nautilus window position or
basically anything - it can also be used to have a "recent devices
plugged in" list. Policy-pieces in KDE or GNOME can set this property -
hal only reads it.

On the topic of attributes for properties, maybe it would be useful to
have owners/permissions? I thought about just having all properties read
only for non-root and having the name space user.* be special in the
sense it is per-user and writable. Maybe this is the easiest to do; I
mean it's probably not useful to read other users properties?

> identical devices:
> For two identical devices, the appended udi-enumeration depends on the
> order of connection time.(?) 

Yep, we have to give them a unique name - but in reality most consumer
devices have something unique we can extract.

> hald can differentiate between them only by
> their topological position. So if a device is discovered, should hald
> look for identical udi's (without the enumeration) and select the record
> with the same topology the record was created for?
> So if you have had two identical devices configured, hald will always
> merge the properties from the device, that was connected to the same
> port?.
> 

This sounds like a good and useful idea. 

An interesting question is whether we should generate a callout when
starting hald and there are no changes to the device-list; I think this
is useful to do but we should probably export an environment variable
called HAL_DEVICE_NOT_CHANGED=true (in search of a better name, heh) for
devices that were there before so the callouts knows what to do. We
should export the same variable when initiating callouts on hald
shutdown, like Joe wants to do in the other mail.

> code:
> Where should the code hook in: device_store.c?
> 

Yep, I think so - we should be able to instantiate a store with or
without persistent storage backing; we currently have the Global Device
List and Temporary Device List. 

In the future, for e.g. diskless thin clients, we might have a device
store per connected X client as well as the one for the computing
server. So, maybe the directory should be
called /var/lib/hal/devices/gdl/... instead?

> thanks,
> Kay
> 

Cheers,
David


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