Re: Hardware Abstraction Layer

[David Zeuthen <david@fubar.dk>]

Greg,

Havoc really touched all your points much better than me, so I'm only
replying to a subset of them.

On Thu, 2003-09-18 at 19:36, Greg KH wrote:
> But my main point is, why store this info anywhere, when it is already
> stored on your machine today?  And it is automatically already handled
> properly today, without any need for "yet another abstraction layer" to
> handle it?
> 

The point of HAL is really to *complement* the information that is
available in, say, Linux kernel 2.6 with sysfs.

Applications care about devices with specific capabilities, not on which
bus they are on, and certainly not how to retrieve it from this or that
bus. They use device-category specific support libraries to do that.
 
The contention is to have properties for each device that links to where
bus-information information is. For example, in Linux Kernel 2.6 you
would have a OS.Linux.devpath property that points somewhere into /sys
for *every* device. 

The advantage of this: When you ask an established device-access library
to do something, you can give it a device-id and it does the job. It
simply looks at the OS.Linux.devpath property from the given device and
does it's magic. Nothing less, Nothing more and quite future proof.

> Yes, I know this only works on Linux, and you want to be
> "cross-platform".  Might I suggest you get the other OSs that you want
> to support to also support what Linux already does, instead of trying to
> duplicate work?
> 

This is not trying to duplicate work at all. It's simply shielding
applications from caring about bus information etc. by moving such
information into libraries. No application should know what USB,
IEEE1394 and so on is...

Also getting everyone to do and emulate what Linux does is not friendly
and it might slow down new and better interfaces both in future versions
of Linux and other places.

> Oh, what oses are you wanting to support?  I think FreeBSD already
> handles much of what Linux does, with it's devfs implementation, but I
> haven't looked at that in a long time to verify this.
> 
> > 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?
> 
> Not really.  I'm getting the impression that you don't realize the
> current state of Linux and how hotplugging and driver loading and device
> naming currently works.  A lot of what you are saying you want to do,
> already works today.
> 

Well, you are right that udev + sysfs is news to me... 

All, I have tried to do is to formulate requirements regarding hardware
from the point of view of desktop environments. I was inspired by
Havoc's paper.

I have tried to be careful to specify everything and initiating
discussion before just coding away. Which is why we are having this
conversation, so I got at least one of my goals right ;-) 

Oh, and I'm also new to open source development!

> The only "major" piece that is missing, is what udev is working on
> solving (the persistant device naming issue.)  Now I agree that udev and
> the hotplug scripts, and the raw hotplug events should get sent using
> dbus events, but I was thinking that userspace programs (like GNOME and
> KDE) that cared about those events would be listening for them.  I
> didn't think there needed to be a whole intermediate layer for these
> messages to have to go through.  But hey, I'm probably missing something
> big here :)
> 

I'm not sure, but these are the key points that HAL tries to solve.

 1. Make access to devices as simple as possible by shielding
    applications from bus-specific things by moving such specifics
    into libraries.

 2. Having a single device info file concept that OEM's ship with
    their devices. This device info file should cover most popular 
    distros and OS'es and versions thereof.
    It should specify what the device is and what the user needs
    to do in order to interact with it. In order to match a device
    do this it need specifics of the hardware like usb.idVendor etc.

 3. Provide some place where user-made settings are stored and persisted
    for a device. For instance UI-things like device name, where to
    mount a storage device and with what options (storage only readable
    by the user or not etc.). 

<rambling>
In fact, things that pop on in the device-list managed by the HAL could
be devices managed by other hosts (USB ports on your remote display,
your fridge, a remote webserver etc.)..
</rambling>

> So is udev.  And yes, I have no problem agreeing on the dbus message
> format.
> 

That sounds good. 

Regards,
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