Talk:Loadable kernel module

This article contains mostly general info about LKM

This article contains mostly general info about LKM and i don't think it needs to be Linux-specific. Linux is OK as an example, though. ~~helix84 15:32, 11 January 2006 (UTC)

So:

• add more Technical details on this page
• use the data inside this article on a generalistic module page

00 tux 01:17, 29 April 2006 (UTC)

KLM or LKM ?

I have heard of LKMs referred-to as KLMs (Kernel Loadable Modules). Is this common usage? Should the KLM initialism also be captured here? ppblais 13:23, 27 April 2006 (UTC)

explain the "loadable"! how is a module loaded an unloaded

I tagged the article as needing cleanup, for several reasons, including what helix84 already mentioned. 70.224.53.241 00:14, 26 June 2006 (UTC)

Rebuilding in Windows

Just wondering, about the rebooting, I didn't know that the kernel in Windows has to be rebuilt before rebooting -- is this true? —The preceding unsigned comment was added by 82.39.136.51 (talk) 12:08, 17 April 2007 (UTC). hello sumit — Preceding unsigned comment added by 101.221.130.134 (talk) 12:42, 31 August 2012 (UTC)

Symbol?

The Linux maintainers tolerate the distribution of proprietary modules, but allow symbols to be marked as only available to GPL modules.

What is a symbol? --Abdull 11:00, 12 November 2007 (UTC)

Basically, "symbol" means a function (routine) or a variable that has a name and is accessible from other pieces of executable. In other words, "symbols" stand for routines and variables that kernel modules may call/use. Trasz (talk) 15:51, 7 January 2009 (UTC)

Detail on loading

The current article seems to provide little detail on the actual process of loading and unloading LKMs. Can anyone provide more information on this, even if it has to be OS-specific? « Aaron Rotenberg « Talk « 05:35, 23 January 2008 (UTC)

Real nature of "tainting"?

Isn't there a category of code that is "open" (in the sense of publicly disclosed) but still "proprietary" (copyrighted or otherwise legally controlled)? Are maintainers put off only by the inability to read the source code, or is there also an issue of tainted "free-ness?" Mrnatural (talk) 19:52, 12 February 2008 (UTC)

API/ABI stability on FreeBSD

With revert 261265695, the reference to ABI Breakage in RELENG_7 (by a member of the FreeBSD release engineering team) was removed, because "it may not be broken. this was a special case, since it didn't affect anything - no filesystem in ports uses that part of the api." Is there a source for that claim? I do not really question this, because neither UPDATING for RELENG_7 nor the 7.1 release notes contain anything about it and neither the announcement nor the commit message list any real consequences, which I would expect. (Anyhow, I thought rebuilding *-kmod ports would have been necessary.) 85.177.240.32 (talk) 21:14, 3 January 2009 (UTC)

As far as I know, the only filesystem in the Ports right now is Fuse. And it's not affected, see http://lists.freebsd.org/pipermail/freebsd-stable/2008-July/043974.html. Trasz (talk) 15:57, 7 January 2009 (UTC)

Section "Security" addendum re: KSplice

Mentioning of a new idea in Linux-Systems to use LKM for hot-patching the kernel might shed a different light on the security of LKM. Or maybe it deserves a entry in See also. 91.37.162.218 (talk) 14:49, 5 July 2009 (UTC)

Security section is a bit unfounded

I don't think that the security section should exist in this article. Kernels that use loadable modules are no less secure than regular monolithic kernels that do not. This is because, assuming someone has the ability to replace (or add) a root kit module, then that means the attacker can probably replace the kernel image itself. Maybe I'm wrong, but it doesn't seem like a valid section. — Preceding unsigned comment added by 24.23.193.92 (talk) 00:31, 24 August 2011 (UTC)

The section already says that, but also explains that an LKM can make it easier to hide the attack. I added a source for that. Jeff Song (talk) 20:05, 12 December 2011 (UTC)

Loadable kernel module - Windows

Windows does NOT use LKM. Its a microkernel OS and hence its modules do not represent LKM. If you think otherwise, please go to Windows article and change its kernel to monolithic type. Until then and until someone also proves its a mono kernel using LKM as extensions, I remove any Windows references from article. 93.129.46.186 (talk) 09:42, 5 May 2013 (UTC)

First, get your facts right. The Windows NT kernel is not a microkernel, it's called a "hybrid kernel". And the "hybrid" part is mostly marketing. All device drivers, file systems, etc still run in kernel mode, just like in a monolithic kernel (see hybrid kernel).

And how exactly are Windows's loadable kernel drivers different from LKM? The fact that Windows doesn't call them "kernel modules" doesn't mean it doesn't have a similar concept.

Another data point, the OS X XNU kernel claims to be a hybrid kernel and supports kernel modules just as well.

-- intgr [talk] 10:44, 5 May 2013 (UTC)

Exactly. See, for example, Microsoft's article on "What Determines When a Driver Is Loaded", which is about "kernel-mode drivers" - i.e., drivers that run in kernel mode rather than user mode - and speaks of when they're loaded. Guy Harris (talk) 18:30, 5 May 2013 (UTC)

NT kernel is and always was highly modular by design. From day 1. Phisically and logically. Not only device drivers but kernel on its own right is composed of different modules: hal, core kernel, base system interface drivers such as pci, drivers for cpu, acpi etc. Windows has the complex driver model and hierarchy. Actually many models. Windows has usermode drivers also. This is far differs from unix clones' recent attemptions to modularize their dinosaur monolitic kernels with some "loadable extensions" for some peripherals. Have these unix clones the different hal or core kernels modules for different configurations which are defined on the fly? Or have they cpu vendor specific loadable drivers? Or acpi? Do they support acpi ever? And "hybrid" is not a "marketing", what a marketing? Stop repeating this bullsh1t like a parrot. Logically, NT kernel has a _microkernel_ and special functional units around it. Executive, object manager, hal, mm. Anyway it is absolutely irrelevant to say that "in Windows it is the same". Windows NT was built 20 years ago with it as base idea of its design, and not as just some poorly integrated option to dynamically load some fs or peripheral device driver instead of statically compile it into the own custom chaotic, sorry, monolitic kernel. Yes, Windows with its "always had" driver model and its internal kernel design and the topic of this article as it is represented now, has nothing to share. Except that these "loadable modules" are the copying of Windows' principles. Copying without acknowledgements though. 77.52.154.156 (talk) 06:41, 13 July 2013 (UTC) ntoskrnl.exe