You are not logged in.
Pages: 1
O.K. I'm really confused.
First of all, just to save myself some embarassement: I am a noob.
I am having trouble with automounting my CD/DVDs ... I won't go on about it in this thread, because this would be wrong. What I would like is some help with understanding the differences and similarities between HAL and udev. I have been reading a lot about them on the Wiki, their development pages, wikipedia, etc, and now I think my head will explode, because I just don't freakin get it.
udev is a daemon that listens to kernel messages regarding the devices in the system. This is done so because the /dev part of the filesystem is filled with all kinds of crap ever mounted or connected to the filesystem. After it hears something like "hey, a device, its name and arguments are: blah" it will try to look this device up in the set of rules that the user writes for this device and mount this device in the filesystem accordingly. So, this means that the udev operations are done on the filesystem level, not the application level (Thunar, Openbox, whatever). This means that if I write a udev rule for my CDs and DVDs (/dev/sr0, but how to distinguish them? Why distinguish them at all?), they would get mounted to some directory, like /media/thankYouDearLordFinallyItWorksThankYou if I write such a rule.
Where the hell is HAL in this? I have read that the udev daemon will redirect the change in the filesystem (after it has mounted or dealt with the device following the rules) to HAL or DeviceKit (Fedora?) and they will inform everyone else through this d-bus thing. How then is HAL on a lower level than kernel?
Why then is the HAL described as a low level implementation of code that interoperates on a lower level than the kernel at the hardware level and it communicates to the hardware even lower than the API?
I am asking all this because I am starting to feel (again) like a total imbecil: I have copied the udev rules for automounting my USB HDDs and they work like a charm. On udev page, I have seen that I can write a these kind of rules for another type of devices like CDs and DVDs (so that they automount like I want them to), and yet, I can't just use udev, can I? If i remove hal from a set of daemons in rc.conf, my keyboard is gone. Just plain gone.
Can I just ditch HAL, write a udev rule for my CDs? The only problem then would be that the applications like Thunar and Virtualbox, and every other app that is searching /media for a cd or dvd would not know that a mount happened? Why then the keyboard drops dead? Why is there no udev daemon in the rc.conf?
I would really appreciate the help, I switched to Arch to learn Linux, and I have finally banged my head hard against a wall...
Thanks.
P.S.
Computational science is a bliss when compared to system administration: there is just too much stuff to absorb here.
Offline
> I can't just use udev, can I? If i remove hal from a set of daemons in rc.conf, my keyboard is gone. Just plain gone
IIRC xorg 1.8 won't be using HAL, only udev. It's just 'round the corner.
Offline
Valid complaints… Glad I can ditch hal in the near future.
Can I just ditch HAL, write a udev rule for my CDs? The only problem then would be that the applications like Thunar and Virtualbox, and every other app that is searching /media for a cd or dvd would not know that a mount happened?
Yes, you can. I remember that orschiro does mount his CDs using udev only (he opened a thread for this, it's sort of lenghty but rather insightful on this issue). How this does affect thunar and vbox I don't know, but IIRC vbox can also access optical media through the device node.
Why then the keyboard drops dead? Why is there no udev daemon in the rc.conf?
You can't remove hal from the daemons line because you probably don't use xorg-server-udev (in the AUR) or xorg-server 1.8. xorg-server-udev doesn't use hal anymore. There's no udev daemon needed in rc.conf because udev is already started during system startup for autoloading modules. Unless you disable autodetecting modules in your mkinitcpio.conf, of course - then you'll have to specify the modules you want to load manually, but don't need udev.
Offline
Yes, you can. I remember that orschiro does mount his CDs using udev only (he opened a thread for this, it's sort of lenghty but rather insightful on this issue). How this does affect thunar and vbox I don't know, but IIRC vbox can also access optical media through the device node.
Thanks for the link on the thread I'll check it out immediately. I still don't get the whole picture regarding the mutual relationship between the two of them. HAL is on top of udev or.. ?
You can't remove hal from the daemons line because you probably don't use xorg-server-udev (in the AUR) or xorg-server 1.8. xorg-server-udev doesn't use hal anymore. There's no udev daemon needed in rc.conf because udev is already started during system startup for autoloading modules. Unless you disable autodetecting modules in your mkinitcpio.conf, of course - then you'll have to specify the modules you want to load manually, but don't need udev.
Thank you! So, X server is relying on HAL... and the AUR one is not... that one is using just udev... cool. O.K., as soon as I'm done with my thesis, I'll use the AUR one. This way, if I understood this right, I can go away from HAL and stick to udev. Right now the hal is needed just because X is relying on it. There is no configuration done in /etc for it, so it seems that udev daemon is taking care of all the automatic mounting. I have read the thread you recommended thouroughly, there seems to be no need for me to use the automount for CDs and DVDs and those guys gave up on it also. I remember when I was using Ubuntu that you can insert whatever CD/DVD you want and it gets mounted and displayed on the desktop (because of Gnome) and if you press to eject it, it gets umounded. The machine was running udev definitely so there has to be some way to configure it to work this way. I will check it out and use /dev/sr0 in the meantime.
> I can't just use udev, can I? If i remove hal from a set of daemons in rc.conf, my keyboard is gone. Just plain gone
IIRC xorg 1.8 won't be using HAL, only udev. It's just 'round the corner.
Thanks, I'll wait a bit then. At least then I will deal with one way to understand the manor in which the device recognition and file system connection works in linux... autofs, HAL, udev, devfs.... what the hell? There is so much of this stuff.... I guess they are all daemons listening to kernel messages and dealing with them by mounting the device files and creating/deleting directories in the file system... that's my conclusion for the time being, details will have to wait for my head to cool down.
Offline
About a year ago I compiled my own X w/o HAL and it worked fine, but I didn't need automount etc.
Edit: I know it's OT, but http://www.makelinux.net/kernel_map will make your head spin
Last edited by karol (2010-04-17 21:49:23)
Offline
About a year ago I compiled my own X w/o HAL and it worked fine, but I didn't need automount etc.
Edit: I know it's OT, but http://www.makelinux.net/kernel_map will make your head spin
I have something like this already in my life, I think two of them is a bit much for now, they would get jelaous of each other and my brain would boil:
http://foam.sourceforge.net/doc/Doxygen … vMesh.html
Thanks a lot for the link, I'll check it out definitely. I'll try not to have a seizure.
Offline
If you're feeling adventurous you can use the pre-built packages, because AUR requires you to compile yourself:
http://mailman.archlinux.org/pipermail/ … 16387.html
You can run this on top of current normally since the OpenSSL upgrade has already been done if you're up to date, but it doesn't hurt to run it on top of testing (which it was originally built against, and any updates will first go to testing).
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline
If you're feeling adventurous you can use the pre-built packages, because AUR requires you to compile yourself:
http://mailman.archlinux.org/pipermail/ … 16387.html
You can run this on top of current normally since the OpenSSL upgrade has already been done if you're up to date, but it doesn't hurt to run it on top of testing (which it was originally built against, and any updates will first go to testing).
Thanks... the thing is.. I must work on my master thesis a lot so I'm a bit scared of tampering with the X right now. If this package isn't mainstream after I graduate, this will be on my agenda. I have put the link in my bookmarks. Thanks! Then I will at least have just the udev to figure out.
Offline
While searching to try to understand udev-hal-dbus stumbled upon
this article: www.linux.com/news/hardware/peripherals/180950-udev
Offline
Pages: 1