Re: hardware query layer

[Havoc Pennington <hp@redhat.com>]

[start of thread at https://listman.redhat.com/pipermail/message-bus-list/2003-April/000353.html]

On Mon, Apr 21, 2003 at 10:15:59PM -0700, Patrick wrote: 
> I've neglected to mention where dbus fits into this since I don't know.
> A quick guess would be that the user-layer library would handle hotplug
> events and general kernel interaction directly via whatever mechanism
> hotplug currently uses and that applications could be notified from this
> user-layer library via dbus.

I think D-BUS is what sends messages from the hotplug system to user
applications. Individual user applications are listening to the
systemwide bus (probably not directly - probably a nice high-level
library provides an API where you just get a "new device callback").

I'll take a stab at the big picture I think we need to present a UI
for hardware that is competitive with OS X or Windows XP and to allow
application/desktop authors to write nice, robust code that does
useful things with devices.

A. Sources of device add/remove messages
===

1. kernel -> hotplug programs/daemons/whatever -> systemwide dbus
2. cupsd -> systemwide dbus                                     
3. X Window System (?) -> systemwide dbus (dunno if this makes sense,
   maybe there would be "xdeviced" that coordinates devices among X
   servers? or just use attribute database, see below)

>From these messages, it's possible to write code that builds and keeps
up to date a consistent big picture of all devices on the system.

B. Device attribute database
===

A persistent collection of text files that uses the standard
factory-defaults/site-local-defaults/user-override pattern 
to merge data that comes with the software, data that comes from OEMs
or is installed by by a local site, and data that a particular user
specifies for themselves (when that makes sense).

These text files should be in a well-defined extensible format and
allow addition of arbitrary new keys (device model number, name,
whatever) and arbitrary new values (device type, whatever).

Ideally, all information about a device that's used anywhere is stored
in one text file - including which driver to load, the kudzu stuff,
whatever - because then users can "install" a device by downloading
and dropping in a single text file.

I would suggest a simple shared library that manages this database and
allows getting/setting/querying. It should also allow apps to monitor
changes to the database, probably by requiring that a message be
broadcast when the database is modified. Or just using file change
monitoring/polling.

[If it isn't clear, "database" doesn't really imply a database, it's
just a bunch of text files, possibly with a "compiled" form for speed]

[Rather than "xdeviced", X servers could also coordinate devices by 
setting a property in the device database indicating which server 
owns the device, which might be interesting]

[There's the caveat that some device info is currently compiled in to
source code so we are still stuck with some duplication between that
and the database probably, unless the database is used both at build
time (generating a header file with hardcoded fallback data) and at
runtime (when available/feasible).]

C. Device abstraction library
===

Linked to by individual user applications; automatically listens to
systemwide dbus events, loads the device database information, or
whatever else is required to build and maintain a list of devices on
the system. 

Imagine a user interface that presents a list of devices, along with
their high-level user visible type (camera etc.), and the list adjusts
dynamically as you add and remove devices. This is how users think 
of devices on their system and also how desktop applications need to 
use them.

The backend for that UI is the device abstraction library. 

The device abstraction library could go as far as seems appropriate by
also abstracting the ability to do things with the devices. For
example, it could allow you to get a handle to the CUPS printer
library object for a printer device. Or it could allow you to check
whether a removable media drive contains media.  Or let you
enable/disable a device, or mount a storage device, or whatever.

In practice, the device abstraction library would probably end up
containing code to handle /etc/fstab and other stuff of that nature.

It could also let you move devices among X servers.

D. General properties
===

1. Surprisingly, almost all of the above should be cross-platform,
   though on some platforms there will inevitably be some no-op stubs
   to be filled in when we get a volunteer.

   If X were involved for example, you'd want the whole stack that X
   required to be fully cross-platform.

   The API used by applications (device abstraction library) would
   definitely be the same on all platforms, though with an "escape hatch"
   ("give me raw /dev/foo for this device").

2. It's broken if specifics of a platform, or specifics of a
   particular device model or bus, leak out to applications.  If you
   have leaks of this nature, then you can't add support for a new
   device model without recoding all the apps. Also, app authors 
   don't understand this stuff and just won't use a lib that 
   forces them too.

   (It's fine if apps *can* get the platform details, but not fine 
   if they *must* get them to do general, common operations. 
   If you have to be unportable to really max out all features of 
   a complicated sound card, then no problem, but simple stuff 
   shouldn't require that.)

3. Libraries should be done robustly (opaque datatypes, thread safety, 
   namespacing, proper API/ABI maintenance, etc.). See some of the 
   X libraries and also GTK+, Qt for best practices.

> Is this appropriate for this list and if not is there a more
> appropriate list I could bring more detailed comments up on?

It isn't really appropriate for this list, but I think there's not an
appropriate list yet so we should tolerate it. ;-)

As I understand it we have some pieces of the puzzle, but we're
missing the two bits of glue, which are the cross-platform device
attribute database and device abstraction library.

I don't know if there's an existing project (specific codebase
regularly released as tarball) that would want to own those two
things, or if it's appropriate to start up a new project for it.
kudzu sort of overlaps, but not entirely. I'm sure there are other
related projects I don't know about.

Of course there are device-type-specific related projects already, 
and it'll take careful talking to the maintainers of those to 
figure out how to proceed. gphoto, foomatic, etc.

Anyway, I'm hoping that if we provide the D-BUS piece we'll be so
close we can taste it, and someone will get excited about the
remaining bits and start up a project and get some momentum.

Havoc
_______________________________________________
Forum mailing list
Forum@XFree86.Org
http://XFree86.Org/mailman/listinfo/forum