0

I've not clear what is the difference between drivers that can be "embedded" inside a monolithic kernel and drivers available only as external modules.

What kind of effort is requested to "port" some driver (provided as "external module" only) to a monolithic kernel?

I would like to be able to run Vmware Tools disabling loadable modules support and getting rid of the initrd bazaar.

klo
  • 3
  • 2
  • what is generally described as "kernel module" is more specifically a DKMS module http://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support ( at least 99.9% of the time ) . But in any case you still need the source code and the support for the branch of the linux kernel that you plan to use on your machine . – user2485710 Dec 01 '13 at 15:05
  • Ok. But what kind of effort is needed to "convert" the source code? The Linux Kernel provides a huge amount of code that can be compiled both as a DKMS module or embedded to a monolithic Kernel. I guess that there is some sort of "common code" and some sort of "module specific" code or makefile settings or what else. I'm not much into this so I would like to understand what is involved. – klo Dec 01 '13 at 15:19
  • Why do you want to use a monolithic kernel? That may help answer your question. – Peter Dec 02 '13 at 15:39
  • Security, Performance, Simple Configuration, Small Footprint, Fast Boot. No flexibility needed. – klo Dec 02 '13 at 21:28

1 Answers1

0

Though the driver more or less remains the same(in both cases),there are definitely benefits for using "drivers" embedded in monolithic kernel.

I'll try to explain the "effort in porting" the driver part which you've asked.

Depending on the kind of driver you've, essentially you've to figure out how it will fit in the current kernel source tree, its compilation(include your .ko in the uImage) and loading of it while kernel booting. Let's illustrate each step a bit:

a.) Locate the folder (in the kernel source tree) where you think it is best suited to keep your driver code.

b.) Work on to make sure your driver code is getting compiled.[i.e ultimately it will be part of monolithic kernel image(uImage or whatever you call it)]. In this context, You've to work on your Makefile for your driver. You might have to introduce some CONFIG flags to compile your driver code. There are tons of Makefiles' and driver code lying in the source tree. Roam around and you will get a good reference of how it is being done.

c.) Make sure that your driver code is independent of any other loadable kernel module(i.e such modules which are not part of the "monolithic" kernel image). Because if you invoke your driver code(which is monolithic now and is in memory) which depends on loadable module code then it may cause some kernel panic/segmentation fault kind of error.

d.) Make sure that your driver is registered with a higher level of subsystem which will be initializing all the registered drivers during boot-up time.(for example: an i2c driver once registered with i2c driver framework will be loaded automatically when i2c subsystem is initialized during system startup). This step might not be really required if you can figure out another way of invoking your driver's __init and __exit functions.

e.) Now, Your Driver _init and (_exit sections) "should" be called if it is getting loaded by any device driver framework or directly(i.e. while kernel is booting up ).

f.) In case of h/w drivers, we have .probe implementation in driver which will be invoked once the kernel finds a corresponding device. In case of s/w drivers, I guess __init and __exit is all you have.

g.) Once it is loaded, you can use it like you were using it earlier as a loadable kernel module

h.) I'll recommend reading source code of similar device drivers in the linux kernel tree and see how they are operating.

Hope this helps.

dkumar
  • 328
  • 2
  • 13