G-P-M on the wrong track?!

[John (J5) Palmieri]

On Sun, 2005-10-16 at 18:04 +0200, Matthias Grimm wrote:
> On Sun, 16 Oct 2005 12:41:26 +0100
> Richard Hughes <hughsient at gmail.com> wrote:
> 
> Hi,
> I split the mail up in three parts, so it keeps readable :-)
> 
> HAL
> -----
> I think the main focus of HAL is to collect data that is helpful for
> desktop applications to inform the desktop user. For example to create
> fitting symbols for newly attached devices, to name those symbols with
> names the user understands (QuickPix USB Camera instead of /dev/sda)
> or the current battery level. Up to here I think we aggree because your
> examples show exact this usage of HAL.

While HAL was indeed conceived by desktop hackers it is actually not
desktop centric.  The real idea for it is to be a one stop store for all
types of applications which abstracts the underlying system away.  It is
a bridge between kernel space and user space which gives a more
consistent view of hardware than different kernels care to.

> My point here is: Where do you draw the border line? Hardware
> Abstraction Layer is a highbrow name but HAL can't never be a real
> hardware abstraction layer. File operation to a hard drive will never go
> through HAL, Sound files will never be played through HAL, Documents
> will never be printed through HAL. 

We went through this many times back when HAL was still in its infancy.
We understood in the end to make HAL useful and accepted it need to
become more of a Hardware Enumeration Layer instead of your traditional
HAL, we however did not specifically say it could not take on a couple
of specialized tasks.  To that end HAL exports policies and calls
callbacks and does a number of other functional thing we though benefit
from abstraction.  While your examples are things we would never do with
HAL, for things like power management it makes sense to allow for
functionality to be called from HAL.

> There are special API's and
> abstraction layers out for this tasks (Kernel, CUPS, ALSA, OSS, etc).
> The HAL specification pointed this out too with a nice graphics: You get
> all necessary information from HAL but talk then to the device directly.

In some cases yes but you are oversimplifying the issues.  For instance
we are not always guaranteed to be running on a Linux Kernel.  

> > Also putting all the ACPI data in HAL has let us fix *many* broken
> > BIOS's, so that any userspace application doesn't have to care about
> > the specific details. I know its not such an issue for the PMU laptops
> > out there, but ACPI is broken more of the time than working.
> 
> Is this the way to go? The kernel has already an ACPI interface in /proc
> and can handle broken BIOSs much better than HAL can. Repairing of
> broken BIOSs is not the task of HAL.

But this is what HAL does.  It culls the info from /proc and other
sources.  On Solaris they are hooking into their framework.

> I think a better solution would be, and I'm quite sure you meant it
> that way, to define schemas for certain elements (like batteries) in HAL
> and fill the data (level, max charge, etc. Whatever is nedded to show
> useful data in a battery monitor on the desktop) nevertheless where the
> data come from (ACPI, APM, PMU or any daemon).

This is how it should work.  If the ACPI layer is the only one written
right now you would just need to write a PMU layer.

> > What's the point? That limits hal to being a flashy version of lspci
> > and lsusb when it has *so much more* potential.
> 
> Partly yes partly no. HAL shouldn't mirror /proc and /sys but provide
> filtered information for desktop applications.

See my first point about the desktop.  The problem with /proc and /sys
is the info is never in a standard format.  I mean look at what has been
accomplished because we added a standard interface.

> > David Zeuthen (HAL maintainer) seemed happy with my changes, and I've
> > got no reason to think that he's not okay with the direction HAL has
> > taken. (David, speak up if you have!)
> 
> This is not a matter of "making someone happy". I would be happy too,
> if you sent so many patches for pbbuttonsd to me :-)
> 
> HAL is going to become an essential part of GNU/Linux desktop systems
> and therefore is must reach an stable state very soon. Application
> programmer must be able to rely on its API and feature set. More
> important than adding new features would be to define the data scheme
> for certain elements so that daemon programmer could fill and desktop
> application programmers could use them.

It is a case by case basis thing.  HAL is pretty stable as is.

-- 
John (J5) Palmieri <johnp at redhat.com>