Help with the Hal deprecation

Hi, I need somebody tell me what is going on with Hal.

Yesterday Carlos told me about Ubuntu’s plans for Karmic and the Hal deprecation. I don’t really know how could I miss this, but I didn’t know before…

Lately I was working a bit with Hal and I kinda like it. As far as I saw, there is a GNOME plan for that deprecation and hal will be split into different pieces which will be integrated into other software. Such a udev-extras, libudev, DeviceKit-*, the kernel itself and so.

I’ve been reading quite a lot about all those changes and I don’t really get the reasons for this move. And I don’t really know how the things will work when the migration be completed.

No more hal at all? No hal-info either? just udev rules (which, btw,  I find really confusing and ugly…)?

I hope someone could help me to see how the things will be at the near future around the hardware layer on GNU/Linux.

Thanks

14 thoughts on “Help with the Hal deprecation”

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

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

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

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

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

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

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

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

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

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

Comments are closed.

Creative Commons Attribution-ShareAlike 3.0 España
This work by Juanje Ojeda is licensed under a Creative Commons Attribution-ShareAlike 3.0 España.