Re: Hardware Abstraction Layer

[David Zeuthen <david@fubar.dk>]

On Thu, 2003-09-18 at 02:29, Greg KH wrote:
> On Wed, Sep 17, 2003 at 02:40:12AM +0200, David Zeuthen wrote:
> > On Tue, 2003-09-16 at 18:39, Greg KH wrote:
> > > On Sat, Sep 13, 2003 at 03:30:38PM +0200, David Zeuthen wrote:
> > > > Hi,
> > > > 
> > > > I'm currently working on a hardware abstraction layer, see
> > > > 
> > > >   http://pdx.freedesktop.org/~hal/
> > > > 
> > > > for use in desktop environments such as GNOME or KDE.  The HAL project
> > > > is in it's early stages - there is a draft spec planned and I got an
> > > > implementation running as well.
> > > 
> > > How does this differ from D-BUS?  Hm, in looking at your page, it says
> > > you are using D-BUS messages.  
> > 
> > I use D-BUS as the IPC mechanism between hotplug agents and applications
> > wanting to query a device database. In the middle there is a daemon. 
> > 
> > In a sense I want the entire HAL not to care about specific hardware
> > issues at all, but build on existing software like linux-hotplug ;-) 
> > (see my recent post to the xdg-list for detail)
> 
> Hm, in looking over your post I think you are going to be duplicating a
> lot of existing information that is dynamically available to you from
> the kernel.
> 

I see your point. You specifically mention the word ''post'', so I'll
assume that you are talking about my initial message to the xdg-list.
This post mentions both ''drivers'' and ''kernel modules'', which I
admit is confusing.

In the latest version, available at the link above, I specifically avoid
using these words and only talk about ''device info files'' and ''boot
programs''. 

The contention is that properties for a device should contain a)
bus-device-specific properties (such as usb.idVendor, usb.bcdDevice,
usb.linux_devfs etc.) and category-specific properties (such as
Storage.Device=/dev/sda1 and Storage.MountPoint=/mnt/flash). 

Applications of the HAL (e.g. desktop environments) will then use
standard kernel and OS interfaces to e.g. display the amount of free
space on a Storage device. 

I hope this clear matters up?

> For example, the kernel already knows what USB devices are supported by
> what drivers.  It exports that info to userspace in the modules.*map
> files in /lib/modules/<KERNEL_VERSION>/
> 
> The existing hotplug scripts already handle the mapping from device to
> driver, so you don't need to duplicate that functionaity.
> 

You are right. Note that the HAL needs to be kernel / OS agnostic but
the idea is to handle this at the device-info level. So, for Linux the
BootProgram for a storage-device simply mounts the device somewhere
chosen by the user or the desktop environment. On other OS'es the
bootprogram may need to insert modules or whatever into a running
kernel.

This implies that, for instance, /etc/hotplug/usb.hotplug will need to
send a DBUS message *after* the kernel modules have been successfully
loaded - see proposal below.

Side question: If a device vendor ships a (kernel) driver for his USB
device will modules.*map get updated?

> > > Oh, have you looked at udev too?  It will
> > > handle naming the devices for you in /dev.
> > > 
> > 
> > Excellent - will look into this later. Will this help me, e.g., getting
> > the information that my CF card reader is at /dev/sda1 when using the
> > kernel module usb-storage? Or have I misunderstood?
> 
> Yes it will.  See my OLS paper from this year for lots more information
> about it.
> 

Great! I'll look into this soon.

> > > Also, D-BUS messages will be
> > > created for all /sbin/hotplug events too.  You might want to work with
> > > that if it's easier for you.
> > > 
> > 
> > I'll be interested in this, definately. Are you using the service
> > org.freedesktop.DBus.Broadcast for this? 
> 
> I'm not using anything :)
> 
> There was a simple command line program that generated dbus messages.
> Someone needs to take that and have it convert hotplug messages into
> dbus messages.  I think it's going to use the org.kernel namespace.
> 

My initial experiments was actually to patch /etc/hotplug/usb.hotplug
and used the same command-line tool. The tool is a bit weak still (but
DBUS is not at 1.0 yet) in so far that obvious data-types like
dictionaries are not available yet. Now I just have a hackish C program
using libdbus to parse the environment given from the kernel and send it
off to the HAL daemon.

IMHO, the best possible scenario for HAL (wrt. hotplugging) would be to
have a well-defined DBUS message scheme for each bus type and
linux-hotplug to implement this broadcasting it through the service
org.freedesktop.DBus.Broadcast. 

Data in these messages would contain the usb.* fields and information
about what (linux) kernel modules was loaded if any (cannot find device
driver etc.).

If there is not a well-defined scheme yet, I'll volunteer to write a
spec and implement it as part of linux-hotplug. We can put this spec at
either the HAL site or the linux-hotplug site. The former would IMHO be
better since we want the scheme to be OS agnostic, but I'm flexible. I'm
quite certain the scheme, to an extent, can be OS agnostic.

What is your take on this?

> > I'll also need a unique ID of each device being hotplugged, and I have
> > some problems seeing this is even possible on some busses like USB. The
> > unique ID must be the same over plugs/unplugs.
> 
> What "unique ID"?  In short, you are never guaranteed such a thing, but
> you can get close.  See my udev paper for more info on this.
> 
> > Say, that I plug two identical cameras into the system with no
> > device-instance specific information. Corner case, but nasty one... 
> 
> Use the bus topology to distinguish between those two devices.
> 
> > In the event this is not possible the hotplug agent must somehow convey
> > this information so I can append a counter to make the ID unique in that
> > way.. 
> 
> The kernel will tell you that this is a new device.  It's up to
> userspace to do something with that info.  udev will determine the /dev
> name for the device.  It's up to other programs to do other things with
> this info (which is what I'm thinking your proposal does, correct?)
> 

Ok, the HAL daemon can take care of this as long as we agree on the DBUS
message format. HAL is strictly user-space.

Thanks,
David




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel