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?_________________[[[ To any NSA and FBI agents reading that text: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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.

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)._________________[[[ To any NSA and FBI agents reading that text: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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._________________[[[ To any NSA and FBI agents reading that text: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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.

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.

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.

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.

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._________________[[[ To any NSA and FBI agents reading that text: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

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.