persistent property store - first try

[Joe Shaw]

On Sat, 2004-06-12 at 22:12 +0200, David Zeuthen wrote:
> > >     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 :-)

I'm having a difficult time coming up with a strong use-case that
fundamentally separates "add" from "change".

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

I think PERSISTENCE should probably be the default, with "stateful"
properties like "volume.is_mounted" explicitly turned off.

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

Some printers have serial numbers which are helpful, but a lot of them
don't and if you have two identical printers plugged in you're likely in
the same situation as having two mice plugged in, etc.

For network cards the mac address gives us uniqueness there.

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

This sounds like a good idea.

Joe


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