I'm now compiling the linux kernel 2.6, and finding there are more than 1,000 modules in total. How is a module approved to be included into the linux kernel?
How’s a module approved to be included into the linux kernel
kernelkernel-modules
Related Solutions
Yes, the reason that essential components (such as mm) cannot be loadable modules is because they are essential -- the kernel will not work without them.
I can't find any references claiming the effects of memory fragmentation with regard to loadable modules is significant, but this part of the LLKM how-to might be interesting reading for you.
I think the question is really part and parcel of the issue of memory fragmentation generally, which happens on two levels: the fragmentation of real memory, which the kernel mm subsystem manages, and the fragmentation of virtual address space which may occur with very large applications (which I'd presume is mostly the result of how they are designed and compiled).
With regard to the fragmentation of real memory, I do not think this is possible at finer than page size (4 KB) granularity. So if you were reading 1 MB of virtually contiguous space that is actually 100% fragmented into 1024 pages, there may be 1000 extra minor operations involved. In that bit of the how-to we read:
The base kernel contains within its prized contiguous domain a large expanse of reusable memory -- the kmalloc pool. In some versions of Linux, the module loader tries first to get contiguous memory from that pool into which to load an LKM and only if a large enough space was not available, go to the vmalloc space. Andi Kleen submitted code to do that in Linux 2.5 in October 2002. He claims the difference is in the several per cent range.
Here the vmalloc space, which is where userspace applications reside, would be that which is potentially prone to fragment into pages. This is simply the reality of contemporary operating systems (they all manage memory via virtual addressing). We might infer from this that virtual addressing could represent a performance penalty of "several percent" in userland as well, but in so far as virtual addressing is necessary and inescapable in userland, it is only in relation to something completely theoretical.
There is the possibility for further compounding fragmentation by the fragmentation of a process's virtual address space (as opposed to the real memory behind it), but this would never apply to kernel modules (whereas the last paragraph apparently could).
If you want my opinion, it is not worth much contemplation. Keep in mind that even with a highly modular kernel, the most used components (fs, networking, etc) will tend to be loaded very early and remain loaded, hence they will certainly be in a contiguous region of real memory, for what it is worth (which might be a reason to not pointlessly load and unload modules).
Doing a kernel module that can use the /proc
filesystem sounds like it might work for you. IBM developerWorks has an article on that topic. I worked through the code a few years ago, and it worked back then. The article is dated 2006, and seems to apply to Linux 2.6 kernels.
The problem I can foresee with using "files" in the /proc
filesystem to get your module to do its work is that an open/read/close style API probably doesn't match what you want to do. You might have to use an open() on a /proc
file to mean "execute WBINVD" or something unobvious like that.
Best Answer
A patch or a git pull request is submitted with a request for comments. This is sometimes done to the kernel mailing list, but is frequently done on other lists pertaining to the subject of the patch first. Sometimes discussion about a proposed module is brought up before any code is even written. People ask why the patch is necessary, state their objections, and point out improvements that could be made. This is an iterative process. When the author is comfortable, he submits it to the Linux kernel mailing list during a time called the merge window.
The moment an official release is made, the opening of the merge window for the next version begins. As part of the closing of the merge window, a patch is either accepted or not. If the patch is accepted, the only further changes to that section of code that are allowed are bug fixes. Also as part of the closing of the merge window, a new RC (release candidate) version of the kernel is released. Almost always, people will have problems with the patch and bugs will need to be fixed or the patch will be reverted.