Comments on: Help with the Hal deprecation

By: Michael T

Michael T — Wed, 16 Sep 2009 11:28:41 +0000

If you’re not worried about portability, sysfs looks like a good bet too. They have certain guarantees about how the API will (not) change in future, and it is pretty easy to write code that will work with kernels back to the early 2.6.x days and still work as GregKH says it should in order to be future-proof. I’m not sure how good it is if you want to poll for new devices though, and finding the matching device nodes can be a bit of a pain without falling back to (newer versions of) udev.

By: Mr. Anderson

Mr. Anderson — Sun, 05 Jul 2009 06:41:55 +0000

It’s just yet another display of people making decisions who shouldn’t be. They cannot separate out an api, componentize code or finish what they start.

I see it time and time again, when someone cannot scale or extend a project they work they unilaterally give up and demand a re-write.

Take a look at the state of sound on the Linux desktop, OSS, ALSA, PulseAudio. Everyone’s a rock star.

Sucks to have to live with such buggy results.

By: juanje

juanje — Wed, 17 Jun 2009 22:44:08 +0000

I’m glad you tell me that. After your response and some research about this topic I think I understand better the plans for Hal, udev, libudev, etc.

By: Simon

Simon — Tue, 16 Jun 2009 22:02:40 +0000

Not quite right. The original plan with DeviceKit was simply a re-write of the increasingly unmaintainable HAL code, taking into account lessons learned with HAL. But it turned out that really, HAL/DeviceKit was just duplicating already available in once central place – udev. So the plan is, if you want hardware info, you talk to udev.

The bit about grasping multiple APIs is little different from before. Previously, if you wanted to get photos off your camera, you either mounted it as a filesystem, or you used libgphoto. Under DeviceKit? Well, you either mount it as a filesystem, or you use libgphoto. Not too different, right?

What *is* changing is that things that got added to HAL that don’t relate directly to device enumeration are being pulled back out again. That’s how HAL started, then stuff like power management and disk management got merged into the core. Now they’re being pulled back out, so instead of calling Suspend() on HAL, you call it on DeviceKit-Power instead. Again, not all that different.

By: juanje

juanje — Tue, 16 Jun 2009 11:10:30 +0000

That’s exactly what I was worry about… I was hopping someone tell me I was wrong

Probably there are good reasons for using libudev, gudev, libgphoto2 and so on but I really hope there will be a centralized and common API for asking for hardware info.

By: FunkyM

FunkyM — Tue, 16 Jun 2009 10:10:07 +0000

The plan: Basically, you forget about getting any hardware info from a central place like it was with HAL. You are thrown back in time before HAL existed and made things easier.

Every software now has to go back doing it the old way and grasp multiple APIs and locations to implement their own hw info grabbing process like before[*].

[*] (Except if there is a DeviceKit-* equivalent available. You should also forget about device enumerations or non-udev platform use.)

By: juanje

juanje — Tue, 16 Jun 2009 07:06:12 +0000

I know. I’ve never said so. The Ubuntu’s plan was the way I found it. Somehow I missed it at the xdg and GNOME lists…

I know the change came (mostly) from David Zeuthen and more people from GNOME and Fedora. And the move is making basicly at Freedesktop.org.

By: drago01

drago01 — Tue, 16 Jun 2009 07:00:30 +0000

You should move to libudev or gudev (gobject based lib ontop of libudev) instead of using hal.

By: anon

anon — Tue, 16 Jun 2009 06:57:36 +0000

It’s not ubuntu who is driving the change . In this case they are just ‘speccing’ out what upstream does .

By: juanje

juanje — Tue, 16 Jun 2009 06:52:46 +0000

Actually I had already readed the link from Jaap and the ones inside the article that Juanjo Marin give me (well not the one from Fedora). But probably I have to read carefully them again to get all the info I need. What I really need is to know how to do some things we (Guadalinex) do by calling Hal through dbus in order to obtain some hardware info with the new scenario.