LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 10-11-2013, 11:05 AM   #16
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-14.1 on a Lenovo T61 6457-4XG
Posts: 4,016

Rep: Reputation: 962Reputation: 962Reputation: 962Reputation: 962Reputation: 962Reputation: 962Reputation: 962Reputation: 962

Patrick Volkerding is the main author of rc.S, that's written in the script.

He didn't forget to explain anything: the purpose of its comment is to warn the user of the consequences of not making rc.udev executable, no more, no less.

Last edited by Didier Spaier; 10-11-2013 at 11:24 AM.
 
Old 10-11-2013, 11:11 AM   #17
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,057

Original Poster
Rep: Reputation: 45
I would have considered it a courtesy at least a slight mentioning of recompilation of some packages. I expect my words will not be taken as a criticism. Nothing farther from my purpose. It's only that the words in rc.S made me feel very comfortable.

ADDENDUM: one of the consecuences you mention, is the need to recompile some packages, provided you want every thing to function flawlessly.

Last edited by stf92; 10-11-2013 at 11:26 AM.
 
Old 10-11-2013, 11:45 AM   #18
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,749

Rep: Reputation: 461Reputation: 461Reputation: 461Reputation: 461Reputation: 461
I'm afraid that there are quite a few packages which cannot be (re)compiled without udev, dbus & Co. -particularly KDE/GNOME/XFCE to name a few. And some of those will not run without them being present -although you could probably link udev to /bin/true to ignore it.

If you are willing to mostly sacrifice using one of the 'big' desktops, you shouldn't have many problems. For device nodes, just install/use the old 'devs-*' package and be done with it. 'devfs' is very ancient -the current 'devtmpfs' does a fine job, but you might need to help it with special device nodes(create them in init scripts or add them manually). And for kernel modules, load them from rc.modules or roll yourself a nice monolithic kernel with everything you need built in.

As for there being notes in rc.S about desktop dependencies/compile order -I doubt that they are relevant there.
 
1 members found this post helpful.
Old 10-11-2013, 11:50 AM   #19
e5150
Member
 
Registered: Oct 2005
Location: Sweden
Distribution: Slackware
Posts: 73

Rep: Reputation: 41
I'm running my system with udev completely removed. With a kernel recompiled without CONFIG_SND_DYNAMIC_MINORS and CONFIG_DEVTMPFS_MOUNT. I've also had to recompile lvm2 and xorg-server.
Unless you know what you're doing you are probably better off with just setting rc.udev non-executable. I would think that both lvm and xorg should work with udev installed but disabled (with AllowEmptyInput set to false in xorg.conf, since otherwise it insists on getting input devices from udev). And a few other programs that link against udev work without modifications as long as libudev.so.0 is available (eg. lsblk from util-linux).
If you are using a (usb) scanner however, you'll probaby run into some problems. Since usbfs was deprecated some time ago, the only way to reliably get non-root access to the scanner seems to be with (udev, or) devtmpfs together with a hotplug script that figures out which usb device the scanner is, and chowns it to :lp (devtmpfs of course, need not be mounted at /dev, if you want to ha a static /dev).
Simply disabling udev shouldn't necessitate a recompile of core packages (except kernel, unless you use something else, e.g. busybox' mdev, to manage permissions of devtmpfs' /dev tree). But I don't know about KDE or other DEs and "desktop applications", I would gess that udisks and NetworkManager couldn't even be compiled without udev support.
 
1 members found this post helpful.
Old 10-11-2013, 12:04 PM   #20
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,057

Original Poster
Rep: Reputation: 45
Quote:
Originally Posted by gnashley View Post
I'm afraid that there are quite a few packages which cannot be (re)compiled without udev, dbus & Co. -particularly KDE/GNOME/XFCE to name a few. And some of those will not run without them being present -although you could probably link udev to /bin/true to ignore it.

If you are willing to mostly sacrifice using one of the 'big' desktops, you shouldn't have many problems. For device nodes, just install/use the old 'devs-*' package and be done with it. 'devfs' is very ancient -the current 'devtmpfs' does a fine job, but you might need to help it with special device nodes(create them in init scripts or add them manually). And for kernel modules, load them from rc.modules or roll yourself a nice monolithic kernel with everything you need built in.

As for there being notes in rc.S about desktop dependencies/compile order -I doubt that they are relevant there.
Ahhh, so the packages that need to be recompiled only affect the GUI behavior, that is, should you not use a GUI at all, the system behavior after the modifications suggested in rc.S would be flawless. And in distribution disk #1://ANNOUNCE.14_0, we read:
Quote:
Slackware 14.0 brings many updates and enhancements, among which
you'll find two of the most advanced desktop environments available
today: Xfce 4.10.0, a fast and lightweight but visually appealing and
easy to use desktop environment, and KDE 4.8.5, a recent stable release
of the 4.8.x series of the award-winning KDE desktop environment.
These desktops utilize udev, udisks, and udisks2, and many of the
specifications from freedesktop.org which allow the system administrator
to grant use of various hardware devices according to users' group
membership so that they will be able to use items such as USB flash
sticks, USB cameras that appear like USB storage, portable hard drives,
CD and DVD media, MP3 players, and more, all without requiring sudo, the
mount or umount command. Just plug and play. Slackware's desktop
should be suitable for any level of Linux experience.
Many thanks for your remarks about a udev-less system.

Last edited by stf92; 10-11-2013 at 12:11 PM.
 
Old 10-11-2013, 12:32 PM   #21
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,057

Original Poster
Rep: Reputation: 45
Thanks for your remarks, e5150. They are welcome in deed.
Quote:
Originally Posted by e5150 View Post
Unless you know what you're doing you are probably better off with just setting rc.udev non-executable.
So no kernel recompilation? But you later add:
Quote:
Simply disabling udev shouldn't necessitate a recompile of core packages (except kernel, [...]) [...]
Should I take it that setting rc.udev non-executable will necessarily need kernel recompilation?

I said it before at the very thread beginning that I'm running slackware 14.0 (x86_64). I repeat it here to help avoid confusions. This distribution uses kernel 3.2.29.

Last edited by stf92; 10-11-2013 at 12:34 PM.
 
Old 10-11-2013, 12:50 PM   #22
e5150
Member
 
Registered: Oct 2005
Location: Sweden
Distribution: Slackware
Posts: 73

Rep: Reputation: 41
Quote:
Originally Posted by stf92 View Post
Thanks for your remarks, e5150. They are welcome in deed.

So no kernel recompilation? But you later add:

Should I take it that setting rc.udev non-executable will necessarily need kernel recompilation?

I said it before at the very thread beginning that I'm running slackware 14.0 (x86_64). I repeat it here to help avoid confusions. This distribution uses kernel 3.2.29.
If you are going for a static /dev you would have to recompile the kernel without DEVTMPFS_MOUNT (which is enabled by default for the stock generic kernel in 14.0), otherwise /dev will be automatically managed by the kernels devtmpfs. So after each reboot you'd have to set all the appropriate permissions on the devices, and maybe create some that devtmpfs doesn't cover (devtmpfs would not detect when I insert an SD-card into my card reader, for example, resulting in a /dev/sdh for the reader, but no sdh1 when there eventually was an actual partition present.)
And you would get problem with your sound unless you disable dynamic minors for sound cards. The help message from kernel configuration states: "If you say Y here, the minor numbers of ALSA device files in /dev/snd/ are allocated dynamically. This allows you to have more than 8 sound cards, but requires a dynamic device file system like udev. If you are unsure about this, say N here."
If you're going to use mdev, or some homebrewn magic script, you might get by, without recompiling the kernel. But for plain old static /dev from the a/devs package, and rc.modules, I'd suggest recomiling without those two setting.

ADDENDUM: What I ment by "just" setting rc.udev non-executable, was, making it non-executable, as opposed to flat out uninstalling udev, which would require recompilation of stuff like xorg-server and lvm. Kernel recompilation is advisable regardless of the method by which you stop using udev.

Last edited by e5150; 10-11-2013 at 12:58 PM.
 
1 members found this post helpful.
Old 10-11-2013, 01:28 PM   #23
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,057

Original Poster
Rep: Reputation: 45
So, if I recompile without [CONFIG_]DEVTMPFS_MOUNT and without CONFIG_SND_DYNAMIC_MINORS, the scenario would likely be this:
Quote:
Originally Posted by e5150 View Post
[...] after each reboot you'd have to set all the appropriate permissions on the devices, and maybe create some that devtmpfs doesn't cover (devtmpfs would not detect when I insert an SD-card into my card reader, for example, resulting in a /dev/sdh for the reader, but no sdh1 when there eventually was an actual partition present.)
And I should respond saying N to the help message from the kernel configuration script (the ALSA thing). I'm writing under the assumption that I will use "plain old static /dev from the a/devs package, and rc.modules", to quote your words.

Quote:
ADDENDUM: What I ment by "just" setting rc.udev non-executable, was, making it non-executable, as opposed to flat out uninstalling udev, which would require recompilation of stuff like xorg-server and lvm. Kernel recompilation is advisable regardless of the method by which you stop using udev.
Your words cannot be clearer. May you have a fine week-end.

Last edited by stf92; 10-11-2013 at 01:42 PM.
 
Old 10-11-2013, 01:53 PM   #24
e5150
Member
 
Registered: Oct 2005
Location: Sweden
Distribution: Slackware
Posts: 73

Rep: Reputation: 41
Quote:
Originally Posted by stf92 View Post
So, if I recompile without [CONFIG_]DEVTMPFS_MOUNT and without CONFIG_SND_DYNAMIC_MINORS, the scenario would likely be this:
If you compile without DEVTMPFS_MOUNT you'll be able to use your static /dev, where you can mknod, chmod and chown as you feel is appropriate (if the defaults from the devs package doesn't suffice). And the changes will be persistent, so you wouldn't need to make changes after each reboot.
Note however, that you can still have devtmpfs enables. It's just that the kernel automounting that gets you into trouble, since devtmpfs creates only the device files that the kernel thinks are needed (similar to what udev does), but (unlike udev) everything is owned by root:root. So with devtmpfs mounted at /dev, you would have to use something like an rc.local that chowns and chmods everything that user needs access to. Creating a /dev/devtmpfs and mounting (by way of fstab) devtmpfs there for reference, might be a good idea.

(It might be possible to unmount an automounted devtmpfs, (maybe `umount -f /dev`?). But you would still be stuck with dynamic minor device numbers for sound cards. So, recompilation is probably your best bet.)

(There is also CONFIG_DVB_DYNAMIC_MINORS and CONFIG_USB_DYNAMIC_MINORS, which requires udev, but they aren't enabled by the stock kernel, so you shouldn't have to take care of those, unless you've explicitly enabled them yourself.)
 
1 members found this post helpful.
Old 10-11-2013, 02:36 PM   #25
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,057

Original Poster
Rep: Reputation: 45
Well, I think after studying this thread and following the advices contained in here, I will be able to enjoy a fully udev-less system (please forgive my clumsiness in understanding your previous post). What good or evil can come out of it is a thing to be seen a posteriori. Plus I see I'm not the only linux user who made up his mind to settle things that way. By the way, may I ask you which is the operating system where you have "completely removed udev"? I mean what linux distrubution and version.
 
Old 10-11-2013, 02:59 PM   #26
e5150
Member
 
Registered: Oct 2005
Location: Sweden
Distribution: Slackware
Posts: 73

Rep: Reputation: 41
Quote:
Originally Posted by stf92 View Post
By the way, may I ask you which is the operating system where you have "completely removed udev"? I mean what linux distrubution and version.
Well, I think it started with slackware 11, when I first ran into a problem where the "proper" solution was to (re)write a udev rule. And it just seemed simpler to uninstall udev. Since then I've run through all slackware(-64) versions, without using udev (I went from 14.0 to current shortly after it was anounced as beta).
(But about once a year I seem to forget what I dislike about udev, and try it out for a few days, but in the end udev always tries to outsmart me (by deciding that my midi-controller should be the primary "sound card", resetting my carefully set permissions, or taking forever to load firmware during boot...), so then I go back to the sanity of the good old days.)
 
1 members found this post helpful.
Old 10-11-2013, 04:16 PM   #27
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,057

Original Poster
Rep: Reputation: 45
Yes, forgetting things like that can be not an uncommon occurrence for people like me, I can tell you. In many systems, I have always asked for minimum automation. When the system is very complex, some things one is forced to let them be automatic. But I prefer manual control over automation and, because of this, little and simple systems over large complex ones. Another reason for this preference is that little systems are easier to understand whereas with larger systems, the number of things one must resign to understand is too great for my taste.

The old days were certainly good and certainly sane. I could, for instance, play with disk direct access, reading/writing whichever physical sector I wanted, or write a program to put the machine into protected mode and go back to real address mode (80x86 processors) after having done some fun things. I could not even dream with doing that with present day operating systems, whereas in those days, a couple of weeks reading the 80286 programmer's reference manual was enough to understand protected mode, and another couple reading its numeric suplement, enabled you to play with the floating-point processor (NPX).

Last edited by stf92; 10-11-2013 at 04:40 PM.
 
Old 10-11-2013, 04:38 PM   #28
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Rep: Reputation: 145Reputation: 145
I don't think you did experience the good "old" days. Otherwise, you would not have been unaware what "devfs" meant and wanted to use it.
 
Old 10-11-2013, 04:43 PM   #29
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,057

Original Poster
Rep: Reputation: 45
The "good old days" were not exclusive to Unix, though it was one of the oldest OSs. Anyways, perhaps I should restrict my use of those words to the time from the launching of the first desktop computers --there were quite a few of them before the IBM PC-- until some given date.

Last edited by stf92; 10-11-2013 at 04:59 PM.
 
Old 10-11-2013, 08:28 PM   #30
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 2,860
Blog Entries: 15

Rep: Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743
That's also why we had HAL and Hotplug which managed devices and auto-mounted drives. It wasn't perfect but it was a lot more sane than udev's rule-kit which still just barely works as well as DeviceKit's less than stellar track record.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Zenwalk 6.4 udev rules for disabling touchpad when usb mouse is plugged ?? hottdogg Zenwalk 0 11-21-2010 08:10 AM
Fedora Core 6 won't start after updates installed - Starting udev: Disabling IRQ #16 Martin01234 Linux - Newbie 3 01-11-2008 06:24 PM
udev: disabling IRQ #20 (or #21) damber Linux - Desktop 0 03-01-2007 09:37 AM
slackware-current, udev 0.96, and custom udev rules not working rignes Slackware 6 08-10-2006 03:43 AM
Slackware - slow on multi task intmail Slackware 7 08-04-2005 08:09 AM


All times are GMT -5. The time now is 03:48 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration