persistent device storage

[Kay Sievers]

On Sun, 2004-05-09 at 22:04 +0200, David Zeuthen wrote:
> 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.

Something like this? 

  string:Camera
  u32   :545324423423
  bool  :0
  double:-21321.3123213334

Or encode the type in the filename?

  product:STR
  capabilities:STR
  persistent:BOL
  number:U32

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

Yeah, sounds reasonable.

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

What about persistence attributes for every property instead of the
whole device. Is it too much? I don't have the whole picture.
There may also be a attribute to prevent Robert's property changed
callout :)

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

Owners/permissions can be the unix file permissions?

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

What about putting the TODO on the Wiki?
I can try to summarize the things about the persistent store and create
a page on the Wiki. What do you think?

thanks,
Kay



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