Re: Hardware Abstraction Layer

[Greg KH <greg@kroah.com>]

On Thu, Sep 18, 2003 at 10:35:45PM +0200, David Zeuthen wrote:
> 
> Greg,
> 
> Havoc really touched all your points much better than me, so I'm only
> replying to a subset of them.

Ok, I just responded back to his message.

> 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.

Agreed.

> 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. 

Makes sense.  udev will be able to provide this to you if you so desire.

> > 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... 

Glad you found it.  Hopefully it will make your life easier for your
Linux implementation.

> 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!

Well, welcome.  Looking forward to a working implementation :)

> > 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.

This seems doable.

>  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.

This might be much more difficult due to the ways different OSs
implement different device support.  But hey, it's good to have dreams.

>  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.). 

Some of that will be taken care of in udev for Linux.  But others (like
where to mount the device) would be up to you.

thanks,

greg k-h


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