[src/trunk]: src/usr.bin/config config(1): TODO about kernel linkage

[uebayasi <uebayasi%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/cc13df7cba7e
branches:  trunk
changeset: 333534:cc13df7cba7e
user:      uebayasi <uebayasi%NetBSD.org@localhost>
date:      Fri Nov 07 16:41:17 2014 +0000

description:
config(1): TODO about kernel linkage

diffstat:

 usr.bin/config/TODO |  46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 46 insertions(+), 0 deletions(-)

diffs (53 lines):

diff -r 6daf7dfe9251 -r cc13df7cba7e usr.bin/config/TODO
--- a/usr.bin/config/TODO       Fri Nov 07 14:57:08 2014 +0000
+++ b/usr.bin/config/TODO       Fri Nov 07 16:41:17 2014 +0000
@@ -183,3 +183,49 @@
   While leaving optimizations as options (CPU specific optimizations, inlined
   bus_space(9) operations, etc.) for users, the official binaries build
   provided by TNF should be as portable as possible.
+
+o Control ELF sections using linker script.
+
+  Now kernel is linked and built directly from object files (*.o).  Each port
+  has an MD linker script, which does everything needed to be done at link
+  time.  As a result, they do from MI alignment restriction (read_mostly,
+  cacheline_aligned) to load address specification for external boot loaders.
+
+  Make this into multiple stages to make linkage more structural.  Especially,
+  reserve the final link for purely MD purpose.
+
+       Monolithic build:
+                    *.o  ---> netbsd.ko        Generic MI linkage
+               netbsd.ko ---> netbsd.ro        Kernel MI linkage
+               netbsd.ro ---> netbsd           Kernel MD linkage
+
+       Modular build (kernel):
+                    *.o  --->      *.ko        Generic + Per-module MI linkage
+                    *.ko ---> netbsd.ro        Kernel MI linkage
+               netbsd.ro ---> netbsd           Kernel MD linkage
+
+       Modular build (module):
+                    *.o  --->      *.ko        Generic + Per-module MI linkage
+                    *.ko --->      *.ro        Modular MI linkage
+                    *.ro --->      *.kmod      Modular MD linkage
+
+  Genric MI linkage is for processing MI linkage that can be applied generally.
+  Data section alignment (.data.read_mostly and .data.cacheline_aligned) is
+  processed here.
+
+  Per-module MI linkage is for modules that want some ordering.  For example,
+  machdep.ko wants to put entry code at the top of .text and .data.
+
+  Kernel MI linkage is for collecting kernel global section data, that is what
+  link-set is used for now.  Once they are collected and symbols to the ranges
+  are assigned, those sections are merged into the pre-existing sections
+  (.rodata) because link-set sections in "netbsd" will never be interpreted by
+  external loaders.
+
+  Kernel MD linkage is used purely for MD purposes, that is, how kernels are
+  loaded by external loaders.  It might be possible that one kernel relocatable
+  (netbsd.ro) is linked into multiple final kernel image (netbsd) for diferent
+  load addresses.
+
+  XXX Modular MI linkage 
+  XXX Modular MD linkage