Linux kernel loaded drivers

How does the Linux kernel know which drivers to load at boot? [closed]

I’d like to know this for the first boot and for subsequent boots. I’m compiling my own kernel and want it to be as lean as possible. I want to build the .config file by hand (mainly as a learning experience), so I need to know everything that can be excluded. I know a possible solution is to look at my current distros list of loaded drivers. However, I’m curious about how my distro discovered what drivers to load initially. TIA.

2 Answers 2

How does the Linux kernel know which drivers to load at boot?

The kernel generates events for devices on e.g. the PCI bus when they are plugged (either hot or cold; events are queued until userspace runs AFAIR). udev will receive these events and do modprobe calls which include the PID/VID (product/vendor IDs) of the device(s); this is usually a string with some * in it. modprobe will then calculate the intersection of the set expressed by udev’s load request wildcard and the set of aliases of kernel modules (themselves being possibly wildcards).

Since USB/Firewire/etc. controllers are usually attached to the PCI bus, that’s how your HCI driver gets loaded. That is how things recurse down; loading is then done with USB/Firewire PID/VIDs of course.

Network protocol modules (e.g. ipv6) are however not dealt with through udev; instead, when a program calls socket(AF_INET6, . ) the kernel directly calls modprobe (more precisely: whatever is in /proc/sys/kernel/modprobe ) with a non-wildcarded alias, net-pf-10 in case of IPv6, because AF_INET6 happens to have value 10. modprobe then loads ipv6.ko , because that is what has the net-pf-10 alias.

Similarly for filesystems, attempting to mount -t foo will cause the kernel to also call modprobe (again, via ____call_usermodehelper ), this time with foo as argument.

Accessing device nodes (e.g. /dev/loop0 , provided it already exists) has the same strategy if loop.ko is not already loaded. The kernel here requests block-major-7-0 (because loop0 usually has (7,0), cf. ls -l ), and loop.ko has the fitting block-major-7-* alias.

Источник

How linux device drivers are loaded?

Can anyone explain me in simple terms the following thing. How Linux drivers are loaded into kernel space? Which functions are exported, after drivers being loaded? How driver functions are called?

1 Answer 1

Normally you will use insmod or modprobe userspace application to load module (and possibly its dependencies in case of the 2nd one). Both of them do the same under the hood to actually load single module — they read the file into memory and use init_module system call, providing address of memory where this module was loaded. This call tells kernel that module should be loaded.

Now kernel modules are actually ELF files and are not much different from shared libraries used in userspace. The kernel has an equivalent of shared library linker, that will parse those files, get a list of symbols that are provided by it, updating the list of functions known to kernel. It will also check if all the symbols that this module needs are already in the kernel and do proper relocations. One of the last thing that it will do is to call initialization function in the module.

Note that you cannot compile the kernel that will directly call any function that is provided by module. Similarly, you can call any function provided by a module in another module before loading the first one. Kernel will refuse to load any module with symbols that are not known. Most of the modules will, however, register its functions as some kind of callbacks that can be called indirectly.

Источник

how a device driver is loaded into linux kernel? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.

Can anyone tell, how a device driver is loaded into linux kernel? means the function call flow. who invokes what? etc., for static and pnp drivers. with some example would be great, like insert USB pen drive kind of stuff. THanks

1 Answer 1

• First of all, to be loaded in the kernel, the driver must be compiled as module.
• The compiled module will have .ko extension.
• The usual location for modules is inside the /lib/modules directory.
• You can have a list of all inserted modules with command lsmod.
• The module is loaded when the system or the user inserts the module (command insmod or modprobe)
• The module_init() function specifies which is the function to be invoked when the module is inserted:

static int __init hello_init(void) < printk(KERN_ALERT "Hello world!\n"); return 0; >module_init(hello_init); 

• allocates (through vmalloc()) the memory to hold the module;
• copies the module into that memory region;
• resolves kernel references in the module via the kernel symbol table (works like the linker ld)
• calls the module’s initialization function.

Related

Hot Network Questions

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.13.43531

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

How does the linux kernel deal with drivers?

I just read about the way Linux deals with hardware drivers. Apparently most of the hardware drivers come pre-compiled into the Linux Kernel. I have some of questions about that. If the Linux kernel contains hardware drivers for almost every hardware device out there, And if a laptop that runs on Linux has only a certain number of hardware devices, Then what about all the redundant hardware drivers that the Linux Kernel has? Is it not a waste of resources to keep all these drivers in the kernel and to keep it up and running in the system even while we are not using them?

device drivers are compiled into modules which are only loaded into the kernel if the relevant hardware is present.

To those that put the question on hold, it was neither over broad nor are there many good answers. I understood the question quite well. Please remove the hold.

Uday Kumar: Your post has two parts. I suggest removing #2, about power efficiency—it’s is a separate question. You could post it separately (but please search first—even if you don’t find an answer, you might narrow it down into something more specific). Part #1, however, seems like a perfectly well-scoped, on-topic question to me. @MarkKirby How are you counting six? Are you reading «what about all the redundant hardware drivers that the Linux Kernel has ?» and «Is it not a waste of resources[. ]» as separate questions? That paragraph looks like a single well-phrased question to me.

@MarkKirby I really don’t think the first three numbered questions in the original post were separate questions. They constituted exposition and clarification of question #1. That they were all answered like a single question, without a need to address them separately, reinforces my belief that they’re asking narrowly about one thing. (In contrast, the last question is separately addressed in that answer, and not in depth, and I think it’s best removed from this post.) Uday Kumar: I still think we can reopen this if (what’s now numbered as) #2 is edited out.

1 Answer 1

First some history. In the earlier days of Linux, device drivers were indeed compiled directly into the kernel. In fact, it’s possible still to compile drivers directly in and many kernels may still have some very common drivers included this way. The way it worked was the generic kernel shipped with the early distributions like SLS or Slackware had virtually every driver the kernel supported compiled directly into it so it would work on the widest possible variety of hardware possible. Even then, it wasn’t possible to put them all in because some of them are mutually incompatible. Then, after you got your system installed, you would build your own kernel, carefully going through the configuration to make sure you included the correct drivers for everything your computer had. Sometimes you had to manually edit header files in the driver to include support for oddball hardware — an Ethernet card that used a particular chipset used that chipset’s drivers, but sometimes there were funny ways it was implemented. Then you’d compile, install, and hopefully after a reboot you then had a custom kernel built for just your computer. Lean and optimized. In reality, you generally repeated this process several times including things you missed, adding support for a filesystem you forgot, or tweaking the settings in some way. Rinse and repeat.

Those days are, thankfully, long past. The kernel has, for a very long time, supported loadable modules. These are kernel drivers compiled so as to become a type of shared library that can be loaded or unloaded on demand. Now the way a kernel boots is you have the kernel file itself and a small compressed filesystem (look at initramfs on Wikipedia) that has in it all the kernel modules that kernel supports. The kernel loads, it finds its initial filesystem and then it can start loading all the drivers it needs.

That little bit of history is skipping a lot of work and sweat along the way. In between using all compiled-in drivers in one huge monolithic kernel and having a fully automated driver loading system we have today were all the steps along that path where we had modules that had to be explicitly loaded, semi-automatic loading for some, etc etc.

So, since modern kernels demand load the vast majority of the drivers they need, there are no significant amount of redundant hardware drivers taking up resources in the kernel of any modern Linux distribution.

Источник

What is the Linux built-in driver load order?

How can we customize the built-in driver load order (to make some built-in driver module load first, and the dependent module load later)?

4 Answers 4

Built-in drivers wont be loaded, hence built-in. Their initialization functions are called and the drivers are activated when kernel sets up itself. These init functions are called in init/main.c::do_initcalls() . All init calls are classified in levels, which are defined in initcall_levels and include/linux/init.h

These levels are actuall symbols defined in linker script ( arch/*/kernel/vmlinux.lds.* ). At kernel compile time, the linker collects all function marked module_init() or other *_initcall() , classify in levels, put all functions in the same level together in the same place, and create like an array of function pointers.

What do_initcall_level() does in the run-time is to call each function pointed by the pointers in the array. There is no calling policy, except levels, in do_initcall_level, but the order in the array is decided in the link time.

So, now you can see that the driver’s initiation order is fixed at the link time, but what can you do?

1. put your init function in the higher level, or
2. put your device driver at the higher position in Makefile

The first one is clear if you’ve read the above. ie) use early_initcall() instead if it is appropriate.

The second one needs a bit more explanation. The reason why the order in a Makefile matter is how the current kernel build system works and how the linkers works. To make a long story short, the build system takes all object files in obj-y and link them together. It is highly environment dependent but there is high probability that the linker place first object file in the obj-y in lower address, thus, called earlier.

If you just want your driver to be called earlier than other drivers in the same directory, this is simplest way to do it.

Источник