Hello!
I've seen that some newer distributions can mount CD's/DVD's automatically, and can unmount them manually, when eject is pressed (and CD isn't in use by application). How can I do same thing in slackware 11?

actually that's quite an old feature (roughly ten years? ).

anyway, you'll need to patch your kernel. the patch is at supermount-ng.sourceforge.net

Thanks! Will try it...

or you can use autofs, no patching required. Although the modern distros use UDEV, DBUS and HAL. I don't like it personally, though

nope, to eject a cd with a mounted filesystem, you _do_ need that patch.

but what do you need then ?

Trouble with using the supermount patch is that it won't compile with gcc-3.4 or greater.
I like the way it works though -I wish I could find out what throws the compile error with newer gcc and fix it. Any ideas ExplainerBear?

sure.
http://gentoo-wiki.com/HOWTO_Supermount

... but reading that; there seems to be a better alternative
http://gentoo-wiki.com/HOWTO_ivman

Thanks! Actually I'm looking for a non-HAL/DBUS solution that works with 2.4 kernels, so Submount is more interesting than ivman, since there is a port.
I found supermount extremely easy to get going and like the functionality for optical drives.
Autofs works fine also.

What's lacking in all of them is good handling of multi-partition devices. So I wrote small program that hooks into USB hotplug events and does what even the others don't -mount and unmount USB devices which have been hotplugged. I use a requester program which a particular user can run, then plug the device in so it 'belong' to him/her. Then the partitions get mounted and managed by root for the user. It even places icons on any desktop(Xlibs) for each partition. Righ-clicking icons showa a menu which lets you unmount/remount each partition or all and refreshes the icons to show status. The menu entries call an SUID program which belongs to the user. The mount/unmount stuff uses su, so you can control which users can actually mount/unmount from your sudoers file.

su is controlled by /etc/suauth
sudo , by /etc/sudoers
did you know, that a lot of 2.6 kernel features were backported to 2.4 by redhat? (among them iirc udev). maybe using those patches and hal/dbus is easier and more maintainable than writing your own program.


btw http://distro.ibiblio.org/pub/linux/...ns/amigolinux/ is an empty folder..

I know my site is empty, right now. Ibiblio had a major hardware failure a couple of weeks ago and I haven't been in shape to start refreshing my download area.

The main reason that I want non-HAL/DBUS is because the API is still unstable. This is also one of the main reasons that I'm no fan of kernel-2.6.x. The SCSI and USB features are still very much in flux and shouldn't be unleashed on the unsuspecting.
I have used some redhat patches before. In fact recently I got NPTL working with kernel-2.4 using a selection of redhat patches. Not that I'm interested in nptl, but other folks are. The patches were for kernel-2.4.20-something and I considered updating the patches for use with current versions. However, the nptl support patches around 160 files so I decided to not go ahead with that. Most people would just use the 2.6 kernel anyway, but I did find threads and e-mails of folks who were building embedded 2.4 systems and needed(maybe just wanted) nptl support.
I also have little interest in using or developing for use with udev. The first thing the devs will tell you that it won't be around long before being replaced by some other system.

In short, these problems are due to the development *model* being used with kernel-2.6. Features and API will only become stable and really usable long-term once they have been abandoned in favor of something else. Not a very good way to achieve 'world domination' if you ask me.
Following the current trend, we'll soon be to the same point as MS products which need a huge base installation in order to do what really could be done with less.

Another contrib to this forum has written an automounter which uses udev. Just the other week he wrote with some questions because his current development code wasn't fubctioning. Turns out there had been a fundamental change in udev which broke his old code. I didn't join his efforts because I didn't want to waste my time in that way. My program does several things that even 2.6 with udev, HAL and DBUS do not do. I know that in a way I'm working backwards, but I have the pleasure of knowing that years from now my code will still work. I do keep one eye trained forward and try to make my code easy to port forward *once there is a stable API upstream to work with*.

Most people who insist on using the 2.6 kernel do so because of missing hardware support. I am always inerested in patches which backport a feature to 2.4. RedHat, because of long-term support for enterprise versions does a pretty good job with many of these features. The only trouble is that the patches don't usually work out-of-box with vanilla sources.

Thanks 'ExplainerBear' I'd forgotten about that one! I was experimenting with Supermount years ago but forgot about it until I read your post. It isn't something you see mentioned everyday...
Could that just be cynicism resulting from the DevFS experience? I think udev will be around for a while yet.... but I might be wrong, since my nose is nowhere near the grindstone...
Could you post a link to it?

I never got around to using the devfs either...
The udev developers themselves will tell you that udev is not 'stable', since the API for HAL and DBUS are not yet stable.

The link to the post about the other project I mentioned is here:
http://www.linuxquestions.org/questi...ghlight=hotmnt

He's just uploaded a new revision (which fixes a breakage caused by changes in udev BTW). I've never gotten around to fully testing his code as it doesn't seem to accomplish much not done by other programs like submount, except that it is all script-based and should work passably without much configuration.

My projects are currently unavailable or I'd certainly post a link to them as well. While I can be quite cynical, my main priority for myself and for my users is that something 'just work' -for my users because they don't want to spend time learning system administration, for myself because I don't want to waste time on system administration/upgrade/fix _I want to develop programs which make the users work easier.

Wait a second. udev has been around for much longer than HAL & DBUS. It's sole function is to provide the ability to have a dynamic /dev directory as opposed to one full of static entries which may or may not be useful on the target machine.

Other than providing this functionality (which is required by HAL & DBUS), udev really doesn't have much to do with these two.
Thanks for that. I'll have a look at it.