HAL substitute

T

tessio

hi there,
I'm just curious to know what will be used to substitute HAL in the FreeBSD port of xorg-server-1.8, since HAL became depreciated in this version.

:?
 
From my understanding the Xorg source first idea was to use and incorporate DeviceKit to completely replace HAL, so it won't need an "external" library to handle devices. However as that is going to be merged with udev(like HAL) I guess that it(xorg) will be using udev user space part, and the kernel part of udev has to be ported to freebsd.
 
"The kernel part of udev" is called "devd" in FreeBSD. There's already a proper, working, usable device management framework in FreeBSD. No need for HAL, DeviceKit, or udev. We have devd.

What sucks, is that none of the Linux devs know how to write a proper front-end/back-end setup for things, and make it portable. KDE Solid is the closest I've seen ... yet it only has a HAL backend currently.

What would have been nice is if HAL and/or DeviceKit had been developed with the ability to switch backends, such that they could use devd properly.
 
phoenix said:
"The kernel part of udev" is called "devd" in FreeBSD. There's already a proper, working, usable device management framework in FreeBSD. No need for HAL, DeviceKit, or udev. We have devd.

What sucks, is that none of the Linux devs know how to write a proper front-end/back-end setup for things, and make it portable. KDE Solid is the closest I've seen ... yet it only has a HAL backend currently.

What would have been nice is if HAL and/or DeviceKit had been developed with the ability to switch backends, such that they could use devd properly.
Click to expand...

Then it looks promising if xorg develops the frontend(probably a aux library) to talk to different backends(devd in freebsd and udev in Linux). DeviceKit is extremely good at switching between backends(in this case the different Linux distributions implementation of udev), which is why I think DeviceKit is merged into the udev source in Linux. One system to rule them all, so to say ;)
 
gilinko said:
DeviceKit is extremely good at switching between backends, which is why I think DeviceKit is merged into the udev source in Linux.
Click to expand...
Call me crazy but doesn't this kinda defeat the purpose of DeviceKit? As a layer between applications (Xorg i.e.) and the kernel devices (udev, devd) i mean.
 
If Im not using a desktop enviroment more than dwm or windowmaker, and hardly ever need to mount anything - is it safe to build xorg without HAL support? Or should I build with support and simpy just dont add it in rc.conf?
 
Yes, it is safe to build and run xorg without hal. Some desktop environments might still want hal.
 
I removed HAL from my system a while ago and I like the sysutils/automounter by Kamikaze. It uses amd very nicely and is not a CPU hogging piece of crap with some weird polling mechanisms.

The setup is very easy, because amd configuration is done fully automagically. And I have never had problems with it. I've had many problems with HAL and the weird gamin thing that peridically makes filesystems unmountable.
 
SirDice said:
Call me crazy but doesn't this kinda defeat the purpose of DeviceKit? As a layer between applications (Xorg i.e.) and the kernel devices (udev, devd) i mean.
Click to expand...

I more feel like calling you sane, but then you must take the usual attitude of the devs involved into account. If they want to merge DeviceKit with udev, they will do so. And if they won't, then he who shall not be mentioned surely will provide a substitute for this.

Somehow I feel like putting a bounty on a linux port of devd. This may be considered evil, but I think it would be a jolly good idea.
 
wblock@ said:
Better to spend that money writing specifications for udev. With that, Warner Losh has offered to write a compatibility version for FreeBSD: http://lists.freebsd.org/pipermail/freebsd-x11/2011-February/010481.html
Click to expand...

I have two problems with that approach.
First, in my book, specificatons for such an elementary component are to be provided by the author of said component. Not doing so is a huge fail. It should not have been commited to the source tree without it.

Second, where is it written that FreeBSD has to play the catch up to Linux?

Yeah, I know. Not gonna happen. But a man can dream, can he?

What I would like to see for FreeBSD even more than udev is a method to freeze jails or the complete OS to a disk file/partition. That I consider more useful, and I research in that direction when I have some spare time at my system. Which is a severly limited resource these days.
 
wblock@ said:
It's not clear to me what that does that sysutils/volman didn't do already.
Click to expand...

volmand doesn't automatically mount devices it finds. vermaden's script does.

volmand only ships with a client for OpenBox. Users of GNOME, KDE, LXDE, XFCE, etc must write their own clients to get things to automatically appear in file managers and what not. vermaden's script provides a simple way to hook into the file manager of your choice.

There's probably other differences. Those are just what I've picked out of the two threads here in the forums.

They do similar things, but in vastly different ways. Not sure which is "better", per se.
 
From what I have checked at volmand, it attaches to devd pipe and reads the events, if some device appears, then volmnad adds it to its 'database' and it can be mounted by using volmand API and like phoenix said, there is currently only Openbox 'client' available.

So as I understand that, volmand can be an addition to my script to also have 'manual' options for mounting/unmounting the attached/detected devices while my script will automount/autounmount anything that is possible to automount/autounmount.
 
You must log in or register to reply here.
Back
Top