FDI merging framework

[David Zeuthen]

On Tue, 2008-08-05 at 09:07 +0100, Richard Hughes 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 think I largely agree with what Kay said; it should be specific to
each subsystem daemon. One thing I'm trying to achieve with the
DeviceKit projects (all three of them) is to provide as few guarantees
as possible while still providing useful technology. It gives us a lot
more freedom to change things in the future.

Now, the idea is that the D-Bus interfaces completely defines the
service in question. It should be possible to reimplement the service in
$FAVORITE_LANGUAGE using $FAVORITE_RUNTIME on $FAVORITE_OPERATING_SYSTEM
(as long as it's relatively UNIX-y). This is also why I'm against
providing shared C libraries to access the service; if you do then lots
of programs start using the libraries and you de-facto force any
implementation to provide such libraries. Don't want to do that.

Hence we need to hide as many details about the underlying OS as
possible. It's still fine to provide Linux-only functionality as long as
you manage the name-space correctly, e.g. like this

 http://hal.freedesktop.org/docs/DeviceKit-disks/Device.html
 (search for Linux)

Hiding as many details as possible from the user of the DeviceKit
services includes dealing with quirky behaviors of the platform in
question; as an example, the user of the D-Bus interface should never
have to worry about quirks. Just for the record, I like to think of
"quirks" as everything we currently use HAL .fdi files for:
suspend/resume quirks, tagging storage device (as card readers or music
players etc.) and so forth. Yes, I use a pretty inclusive definition of
the word "quirk".

Thus, the reference implementations (that currently includes the D-Bus
interface definitions though this make change at some point) should
therefore consider quirks an implementation detail. Hence, I think it's
fine for the reference implementations on Linux to just use the native
device database and device tagging infrastructure: udev. In other words
it's fine to use udev rules for now. On the BSD's and Solaris, similar
native technologies can be used.

In the future (but not something I'm planning to work on right away and
not something I think is urgent), we may define a super-quirk format
that is portable among operating systems (much like HAL fdi files). Then
we can simply generate native files (e.g. udev rules on Linux) from
that. But I don't think it's urgent to do this just yet.

Thoughts?

     David