One major change is that HAL will not (initially at least, if ever) go into device configuration such as mounting a disk or loading a kernel driver.
Features like this really belong in separate subsystems. Having said that, HAL will certainly be useful when writing such things. For instance a volume manager, as proposed by Carlos Perelló Marín on the xdg-list, should (excluding the optical drive parts) be straightforward to write insofar that such a program will just listen for D-BUS events from the HAL daemon when storage devices are added/removed, and mount/unmount them.
Finally, the need for Free Device Information files (.fdi files) won't be that big initially since most of the smart busses (USB, PCI) provide device class information that we can map to HAL device capabilities. However, some devices (like my Canon Digital IXUS v camera) just report the class / interface as proprietary so it is needed.
There are a lot of other reasons for supplying .fdi files though. First of all some capabilities of a device that DE's are interested are hard/impossible to guess. For example, people should be able to use a digital camera and mp3 player as a storage device as many people already do. Second, having .fdi files gives the opportunity to fine tune the names of the device and maybe even localize it into many languages. Third, we can advertise certain known bugs or deficiencies in the device for the libraries/servers using the device.
Rayiner Hashem: HAL seems to overlap in a lot of ways existing mechanisms like hotplug and kudzu. Will HAL interoperate with these projects or replace them entirely?
David Zeuthen: HAL might replace kudzu one day when we get more into device configuration. In the mean time both mechanisms can peacefully coexist.
For linux-hotplug, and udev for that matter, I'd say the goal is definately to interoperate for a number of reasons; first of all linux-hotplug is already widely deployed and it works pretty well; second it may not be in a vendors best interest to deploy HAL on an embedded device (though HAL will be lean and only depend on D-BUS) because of resource issues. Finally, it's too early for HAL to go into device configuration as noted above.
Rayiner Hashem: HAL is seperate from the underlying kernel mechanisms that handle the actual device management. Is there a chance, then, that information could get out of sync, with HAL having one hardware list and the kernel having another? If so, are there any mechanisms in place that would prevent this from happening, or allow the user to fix things manually?
David Zeuthen: There is always the possibility of this happening, but with the current design I'd say that the changes are slim. Upon invocation of the HAL daemon all busses are probed (via a kernel interface) and devices are removed/added as appropriate using the linux-hotplug facilities.
There will be a set of tools shipped with HAL; one of them will wipe the entire device list and reprobe the devices. I do hope this will never be needed though :-)
Eugenia Loli-Queru: Gnome/KDE are multiplatform DEs, but HAL for now is pretty tied to Linux. If HAL is to be part of Gnome/KDE, how easy/difficult would be to port it on BSDs or other Unices?
David Zeuthen: With the new architecture most of the HAL parts are OS agnostic; specifically the only Linux-specific parts are less than 2000 lines of C code for handling USB and PCI devices using the kernel 2.6 sysfs interface. It will probably grow to 3-4k LOC when block devices are supported.
The insulation from the OS is important, not only for supporting FreeBSD, Solaris and other UNIX and UNIX-like systems, but more importantly, it allows OS'es that said DE's run on to make drastic changes without affecting the DE's. So, maybe we won't get FreeBSD support for the next release of HAL, but anyone is able to add it when they feel like it.
I'd like to add a few things on the road map for HAL. The next release (due in a few weeks give and take), will be quite simple insofar that it basically just gives a list of devices. It will also require Linux Kernel 2.6 which may be a problem for some people (but they are free to write the Linux 2.4 parts; I already got USB support for 2.4)..
Part of the release will also feature a GUI "Device Manager" to show the devices. Work-in-progress screenshots are here.
Post 0.2 (or 0.3 when it's stable) I think it will be time to look into integrating HAL into existing device libraries such that programmers can basically just throw a HAL object and get the library to do the stuff; this will of course require buy-in from such projects as it adds D-BUS and, maybe, HAL as a dependency. Work on a volume manager will also be possible post 0.2.
It may be pretentious, but in time I'd also like to see existing display and audio servers use HAL. For instance, an X server could get the list of graphic cards (and monitors) from HAL and store settings in properties under it's own namespace (FDOXserver.width etc.). This way it will be a lot easier to write configuration tools, especially since D-BUS sports Python bindings instead of editing an arcane XFree86Config file.
There is a lot of crazy, and not so crazy, ideas we can start to explore when the basics are working: Security (only daddy can use daddy's camera), Per-user settings (could store name of camera for display in GNOME/KDE), Network Transparency (plug an USB device into your X-terminal and use it on the computing server you connect to).
The Fedora developers are also looking into creating a hardware web site, see here so the device manager could find .fdi files this way (of course this must be done a distro/OS independent way).