View previous topic :: View next topic |
Author |
Message |
Dominique_71 Veteran
Joined: 17 Aug 2005 Posts: 1879 Location: Switzerland (Romandie)
|
Posted: Wed Jan 23, 2013 6:32 pm Post subject: What possibilities exist to load modules at boot? |
|
|
I am curious about the different possibilities to load kernel modules at boot time. I can see several possibilities:
a) modules into the kernel using boot parameters for modules options
b) custon scripts with static /dev
c) udev
d) sytemd
I think a) will need a static /dev because the kernel will be loaded before udev and systemd. But I am not 100% sure. Is a) in need of a static udev, or will it also work with, or will it need udev or systemd?
More generally, are those 4 possibilities the only ones, or am I missing something? _________________ "Confirm You are a robot." - the singularity |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54420 Location: 56N 3W
|
Posted: Wed Jan 23, 2013 7:43 pm Post subject: |
|
|
Dominique_71,
You need DEVTMPFS in the kernel, then the mount DEVTMPFS at boot kernel options.
This is more about getting and early dynamic /dev than about module loading.
You can also list kernel modules to be loaded in /etc/conf.d/modules - follow the help in the file.
/dev is about providing device nodes for hardware devices to be attached for so that they can be used.
module loading is about providing device drivers. The two things are not the same thing nor are they directly linked.
In the days of a complete static /dev tree, every device node known to the kernel was present in /dev.
Very few were actually usable as
a) there was no hardware behind most of the nodes
b) there were no drivers loaded for all of the non-existant hardware. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
dmpogo Advocate
Joined: 02 Sep 2004 Posts: 3269 Location: Canada
|
Posted: Thu Jan 24, 2013 8:11 am Post subject: |
|
|
NeddySeagoon wrote: | Dominique_71,
In the days of a complete static /dev tree, every device node known to the kernel was present in /dev.
|
Not all as far as I remember - just the common ones, with some overkill. From time to time one had to create
a node for a new device, although it was often taken care of by, say, RedHat rpm installer.
I surely never had 65 tty's back with static /dev as I have no with udev (there is a lot of some /dev/vcs devices created by udev which I never bothered to find out about) |
|
Back to top |
|
|
Dominique_71 Veteran
Joined: 17 Aug 2005 Posts: 1879 Location: Switzerland (Romandie)
|
Posted: Thu Jan 24, 2013 6:07 pm Post subject: |
|
|
NeddySeagoon wrote: | Dominique_71,
You need DEVTMPFS in the kernel, then the mount DEVTMPFS at boot kernel options.
This is more about getting and early dynamic /dev than about module loading. |
It is at least one guy on the alsa-users list that use a static /dev with 3.6 kernel. He just don't want udev, and he doesn't use DEPRECATED_SYSFS.
NeddySeagoon wrote: | You can also list kernel modules to be loaded in /etc/conf.d/modules - follow the help in the file. |
When using udev. They will do nothing if someone is not using udev, or I missed something.
I don't know if those config files are also used by systemd.
(I am not stressed at all to try systemd, and seriously hoping the guy/company behind it will do his/their own OS instead of polluting linux with it. It's just what I think about it for the moment, I may be wrong, and that's another subject.)
NeddySeagoon wrote: | /dev is about providing device nodes for hardware devices to be attached for so that they can be used.
module loading is about providing device drivers. The two things are not the same thing nor are they directly linked. |
If I am right, DEVTMPSFS give us a dynamic /dev when using udev or systemd, but DEVTMPFS can be used without udev and systemd. In that last case, the sysadmin will have to create custom scripts to create the /dev hierarchy and load the drivers (modules). _________________ "Confirm You are a robot." - the singularity |
|
Back to top |
|
|
Dominique_71 Veteran
Joined: 17 Aug 2005 Posts: 1879 Location: Switzerland (Romandie)
|
Posted: Thu Jan 24, 2013 6:16 pm Post subject: |
|
|
dmpogo wrote: | NeddySeagoon wrote: | Dominique_71,
In the days of a complete static /dev tree, every device node known to the kernel was present in /dev.
|
Not all as far as I remember - just the common ones, with some overkill. From time to time one had to create
a node for a new device, although it was often taken care of by, say, RedHat rpm installer. |
RedHat is not a good example for me. I try it several times on several computers. The only one time the installation did succeed, the result was a kernel panic at boot. Maybe is it for that they try to force stuffs like polkit and systemd instead of learning how to make an installable and usable GNU/linux system
I'm joking here, but the first part with my RedHat experiences is sadly true. And I never get that kind of troubles with other distributions inclusive Suse, Debian or more recently Ubuntu. _________________ "Confirm You are a robot." - the singularity |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54420 Location: 56N 3W
|
Posted: Thu Jan 24, 2013 6:19 pm Post subject: |
|
|
Dominique_71,
It varies with kernel version. Currently DEVTMPFS makes and destroys /dev nodes for hardware the kernel notices coming and going.
udev gets a kernel event to the hardware change which it uses to fix the permissions on the /dev node, possibly load a kernel module and run any other user defined rules.
The file /etc/init.d/modules is fed to modprobe during the boot process by openrc. The listed modules and there parameters are loaded regardless of udev, except that udev may already have loaded the module.
One example where the automatics still fail is network card modules. If its not listed in /etc/init.d/modules and its not build into the kernel, you will need to run modprobe yourself. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
dmpogo Advocate
Joined: 02 Sep 2004 Posts: 3269 Location: Canada
|
Posted: Thu Jan 24, 2013 9:29 pm Post subject: |
|
|
Dominique_71 wrote: | dmpogo wrote: | NeddySeagoon wrote: | Dominique_71,
In the days of a complete static /dev tree, every device node known to the kernel was present in /dev.
|
Not all as far as I remember - just the common ones, with some overkill. From time to time one had to create
a node for a new device, although it was often taken care of by, say, RedHat rpm installer. |
RedHat is not a good example for me. I try it several times on several computers. The only one time the installation did succeed, the result was a kernel panic at boot. Maybe is it for that they try to force stuffs like polkit and systemd instead of learning how to make an installable and usable GNU/linux system
I'm joking here, but the first part with my RedHat experiences is sadly true. And I never get that kind of troubles with other distributions inclusive Suse, Debian or more recently Ubuntu. |
Well, I used Redhat from 1998 to 2003, don't know much ones it came Fedora. Back in 1998, though I knew user side of Unix, I was pretty clueless about system internals when I poped in my first RedHat CD. Never had real problem with it, somehow. |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9554 Location: beyond the rim
|
Posted: Fri Jan 25, 2013 2:15 pm Post subject: |
|
|
I think you're confusing different things here and actually asking the wrong question as a result.
Lets start with some definitions:
- The kernel contains drivers, either built in statically or loadable as modules
- Most (not all) drivers can interact with userspace over a device node
- Device nodes are typically located in the /dev hierarchy
- There are different ways to manage device nodes ([e]udev, mdev, static dev, devtmpfs) which aren't mutually exclusive, e.g. you can use udev on top of devtmpfs
- There are different ways to load driver modules (openrc, udev, manually) which again aren't mutually exclusive
The main point is that driver loading is independent from how /dev is managed. The standard right now is that udev is used for both which I assume caused the confusion for you.
Also don't confuse sysfs and devtmpfs, those are different things.
This is probably not what you were looking for, but maybe it helps you to ask the right question. |
|
Back to top |
|
|
Dominique_71 Veteran
Joined: 17 Aug 2005 Posts: 1879 Location: Switzerland (Romandie)
|
Posted: Fri Jan 25, 2013 6:43 pm Post subject: |
|
|
Genone wrote: | I think you're confusing different things here and actually asking the wrong question as a result.
Lets start with some definitions:
- The kernel contains drivers, either built in statically or loadable as modules
- Most (not all) drivers can interact with userspace over a device node
- Device nodes are typically located in the /dev hierarchy |
I know.
Genone wrote: | - There are different ways to manage device nodes ([e]udev, mdev, static dev, devtmpfs) which aren't mutually exclusive, e.g. you can use udev on top of devtmpfs |
I know it's different ways to manage devices nodes, and I understood they are not mutually exclusive yesterday, by reading NeddySeagoon answer and with some search and rtfm.
Genone wrote: | - There are different ways to load driver modules (openrc, udev, manually) which again aren't mutually exclusive
The main point is that driver loading is independent from how /dev is managed. |
So, a linux based system can use any combination of them.
Genone wrote: | The standard right now is that udev is used for both which I assume caused the confusion for you. |
You are right. Thank you for the clarification.
Genone wrote: | Also don't confuse sysfs and devtmpfs, those are different things. |
From Linux from scratch: 7.4. Device and Module Handling on an LFS System, if I understand right, sysfs in /sys is where the kernel describe the hardware. That information can be used by udev and by userspace.
And devtempfs in /dev is where udev actually mount the drivers, which make possible for userspace to access the hardware.
Genone wrote: | This is probably not what you were looking for, but maybe it helps you to ask the right question. |
It is always more difficult to ask the right question when you are confusing things. And it was what I was doing. Anyway, I get more answers than wanted and it make me happy, because I get good clarifications on an important issue.
I will read more of the Linux from scratch documentation. _________________ "Confirm You are a robot." - the singularity |
|
Back to top |
|
|
hcaulfield57 Tux's lil' helper
Joined: 13 Mar 2012 Posts: 148
|
Posted: Tue Feb 05, 2013 6:10 pm Post subject: |
|
|
Dominique_71 wrote: |
It is at least one guy on the alsa-users list that use a static /dev with 3.6 kernel. He just don't want udev, and he doesn't use DEPRECATED_SYSFS.
|
In general you don't need udev, only a few things will break, that are for most users probably not necessary. _________________ "To design the perfect anti-Unix, make all file formats binary and opaque, and require heavyweight tools to read and edit them." - The Art of Unix Programming |
|
Back to top |
|
|
sundialsvc4 Guru
Joined: 10 Nov 2005 Posts: 436
|
Posted: Thu Feb 14, 2013 3:02 am Post subject: |
|
|
One thing that I did very early on was to identify what drivers were actually needed for the non-removable hardware (and the removable stuff that's attached most of the time), and put it directly into the kernel. The system does run udev, does set up the "/dev" tree etc. based on what it finds, but it never has to search for a module to load at any time in the bootup process. That speeds things up a lot. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|