FDI merging framework

[Kay Sievers]

On Tue, Aug 5, 2008 at 10:07, Richard Hughes <hughsient at gmail.com> wrote:
> Do we have any ideas how the quirk and meta-data information store is
> going to look like in DeviceKit? After talking to DavidZ in Boston it
> would be nice to have a meta-fdi framework, with which we can generate
> HAL fdi files and also DeviceKit (whatever) files.
>
> I'll be needing this functionality for DK-power for the pm-utils quirks
> and also some broken battery support that we can't push down into the
> kernel.

I expect the subsystem daemons will implement their own
matching/config/setup logic. A lot of the current fdi functionality,
like device-classification and global device settings, can just move
down to udev rules, where they fit better into todays model, and the
subsystem specific data will just live in the subsystem daemons, to
fit their specific need. I do not think, that besides udev rules,
which will provide simple KEY=value environment keys along with the
event, we will be able to share too many things between the different
subsystems at this level.

For the -power case, you need to store your history of events and
measured values somewhere, much like dk-disks stores SMART data and
such, in its own database. It does not really make sense to try to put
that into some globaI unified thing. So I think, we should not try
again to come up again with any abstract model, which could possibly
be shared between subsystems - in reality it likely causes more
problems than is solves.

The well-defined interface, which can not be changed without proper
coordination, is the subsystem-D-Bus-interface, the introspection
file. All other things are private to the platform and the subsystem
and can be changed as needed, as applications must not depend on it. I
do not expect any global device database to exist, which will be
visible to applications, like hal is today.

I guess from todays picture, the rule would be, that all stuff which
does not fit properly into (rather simple) udev rules, should go as a
private implementation into the individual subsystem daemons, which
can, if needed, maintain/define their own config
files/databases/storage to fit their own need.

Kay