summaryrefslogtreecommitdiffstats
diff options
authorMcgrof <anonymous.contributor@example.org>2014-11-05 23:38:48 +0000
committerKonstantin Ryabitsev <konstantin@linuxfoundation.org>2024-10-04 15:47:32 -0400
commit2cc69aa6158c71373174c4b915e4e3e8348de848 (patch)
treeac8bb7d11a75f9fadc2c16bd06b1f73793fd2ed8
parente6a3a214a12f869b2f6dbf25649c42cc0a8b5ed5 (diff)
downloadbackports-2cc69aa6158c71373174c4b915e4e3e8348de848.tar.gz
Update Documentation/backports/hacking/todo
-rw-r--r--wiki/Documentation_backports_hacking_todo.mediawiki21
1 files changed, 21 insertions, 0 deletions
diff --git a/wiki/Documentation_backports_hacking_todo.mediawiki b/wiki/Documentation_backports_hacking_todo.mediawiki
index db5f581..46238ac 100644
--- a/wiki/Documentation_backports_hacking_todo.mediawiki
+++ b/wiki/Documentation_backports_hacking_todo.mediawiki
@@ -44,6 +44,27 @@ Module namespace can consist of either adding prefixes to existing symbols or mo
Andi Kleen introduced the modular structure modification version of [http://thread.gmane.org/gmane.linux.network/78674 module namespaces] back in 2007 but [http://article.gmane.org/gmane.linux.kernel/606885 Rusty Russell nacked these patches]. Because of this we're left with remapping modules to their own namespaces without modifying the in-kernel module structure. It '''may''' be possible to somehow provide module namespaces without requiring modifications to the in-kernel module structure, but such mechanisms would end up being hacks. We need to evaluate if we can figure a clever way to support this that is not so error prone or if we want to respinning Andi's patches with the intent to help support kernel backporting.
+== Original motivation for module namespaces ==
+
+Here's a brain dump from Andi about the original motivation behind module namespaces:
+
+The original intent was to provide a cleaner export symbol API.
+
+There are roughly two classes of exported symbols:
+
+- Generally usable, well designed, interfaces intended to be used by multiple
+modules (e.g. functions for drivers to register themselves or
+library functions)
+
+- Special purpose exports that are only really for a single
+module, but are not intended as a general interface. These interfaces
+are usually not really clean and reusable.
+
+The idea was to mark the later special purpose exports with the name of the
+module that is supposed to them. They wouldn't be available
+to everybody else and wouldn't become part of the general
+kernel module API.
+
== Motivations ==
At times Linux distributions may choose, for whatever support-nightmare reasons, to support two versions of a subsystem module and have two separate device drivers use a different version of that subsystem. The reason this is ill-advised is we stand to gain by having development done on the upstream and latest versions of each subsystem and drivers; that backports framework allows you to get that. An example helps to clarify here. Suppose a distribution wants to ship with an old version of mac80211 and have the iwlwifi driver use it, but for ath9k they'd want to ship the newer version of mac80211 and new version of ath9k. This cannot be supported unless module namespaces are created.