G-P-M on the wrong track?!

[Matthias Grimm]

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.

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

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

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

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

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

For example:
   battery {
     charge level
     max charge level
     temperature
     discharge cycle no.
     ...
   }

I think HAL don't need to get the data itself in most of the cases.

 Best Regards
   Matthias