TODO revision 1.12 
1o Call module as module.
2
3  Until now, everything is called as attribute.  Separate module from it:
4
5	- Module is a collection of code (*.[cSo]), and provides a function.
6	  Module can depend on other modules.
7
8	- Attribute provides metadata for modules.  One module can have
9	  multiple attributes.  Attribute doesn't generate a module (*.o,
10	  *.ko).
11
12o Emit everything (ioconf.*, Makefile, ...) per-attribute.
13
14  config(9) related metadata (cfdriver, cfattach, cfdata, ...) should be
15  collected using linker.  Create ELF sections like
16  .{rodata,data}.config.{cfdriver,cfattach,cfdata}.  Provide reference
17  symbols (e.g. cfdriverinit[]) using linker script.  Sort entries by name
18  to lookup entries by binary search in kernel.
19
20o Generate modular(9) related information.  Especially module dependency.
21
22  At this moment modular(9) modules hardcode dependency in *.c using the
23  MODULE() macro:
24
25	MODULE(MODULE_CLASS_DRIVER, hdaudio, "pci");
26
27  This information already exists in config(5) definitions (files.*).
28  Extend config(5) to be able to specify module's class.
29
30  Ideally these module metadata are kept somewhere in ELF headers, so that
31  loaders (e.g. boot(8)) can easily read.  One idea is to abuse DYNAMIC
32  sections to record dependency, as shared library does.  (Feasibility
33  unknown.)
34
35o Rename "interface attribute" to "bus".
36
37  Instead of
38
39	define	audiobus {}
40	attach	audio at audiobus
41
42  Do like this
43
44	defbus	audiobus {}
45	attach	audio at audiobus
46
47o Retire "attach foo at bar with foo_bar.c"
48
49  Most of these should be rewritten by defining a common interface attribute
50  "foobus", instead of writing multiple attachments.  com(4), ld(4), ehci(4)
51  are typical examples.  For ehci(4), EHCI-capable controller drivers implement
52  "ehcibus" interface, like:
53
54	defne	ehcibus {}
55	device	imxehci: ehcibus
56
57  These drivers' attach functions call config_found() to attach ehci(4) via
58  the "ehcibus" interface attribute, instead of calling ehci_init() directly.
59  Same for com(4) (com_attach_subr()) and ld(4) (ldattach()).
60
61o Sort objects in more reasonable order.
62
63  Put machdep.ko in the lowest address.  uvm.ko and kern.ko follow.
64
65  Kill alphabetical sort (${OBJS:O} in sys/conf/Makefile.inc.kern.
66
67  Use ldscript.  Do like this
68
69	.text :
70	AT (ADDR(.text) & 0x0fffffff)
71	{
72	  *(.text.machdep.locore.entry)
73	  *(.text.machdep.locore)
74	  *(.text.machdep)
75	  *(.text)
76	  *(.text.*)
77	  :
78
79  Kill linker definitions in sys/conf/Makefile.inc.kern.
80
81o Differentiate "options" and "flags"/"params".
82
83  "options" enables features by adding *.c files (via attributes).
84
85  "flags" and "params" are to change contents of *.c files.  These don't add
86  *.c files to the result kernel, or don't build attributes (modules).
87
88o Make flags/params per attributes (modules).
89
90  Basically flags and params are cpp(1) #define's generated in opt_*.h.  Make
91  them local to one attributes (modules).  Flags/params which affects files
92  across attributes (modules) are possible, but should be discouraged.
93
94o Generate things only by definitions.
95
96  In the ideal dynamically modular world, "selection" will be done not at
97  compile time but at runtime.  Users select their wanted modules, by
98  dynamically loading them.
99
100  This means that the system provides all choices; that is, build all modules
101  in the source tree.  Necessary information is defined in the "definition"
102  part.
103
104o Split cfdata.
105
106  cfdata is a set of pattern matching rules to enable devices at runtime device
107  auto-configuration.  It is pure data and can (should) be generated separately
108  from the code.
109
110o Allow easier adding and removing of options.
111
112  It should be possible to add or remove options, flags, etc.,
113  without regard to whether or not they are already defined.
114  For example, a configuration like this:
115
116	include GENERIC
117	options FOO
118	no options BAR
119
120  should work regardless of whether or not options FOO and/or
121  options BAR were defined in GENERIC.  It should not give
122  errors like "options BAR was already defined" or "options FOO
123  was not defined".
124
125o Introduce "class".
126
127  Every module should be classified as at least one class, as modular(9)
128  modules already do.  For example, file systems are marked as "vfs", network
129  protocols are "netproto".
130
131  Consider to merge "devclass" into "class".
132
133  For syntax clarity, class names could be used as a keyword to select the
134  class's instance module:
135
136	# Define net80211 module as netproto class
137	class netproto
138	define net80211: netproto
139
140	# Select net80211 to be builtin
141	netproto net80211
142
143  Accordingly device/attach selection syntax should be revisited.
144
145o Support kernel constructor/destructor (.kctors/.kdtors)
146
147  Initialization and finalization should be called via constructors and
148  destructors.  Don't hardcode those sequences as sys/kern/init_main.c:main()
149  does.
150
151  The order of .kctors/.kdtors is resolved by dependency.  The difference from
152  userland is that in kernel depended ones are located in lower addresses;
153  "machdep" module is the lowest.  Thus the lowest entry in .ctors must be
154  executed the first.
155
156  The .kctors/.kdtors entries are executed by kernel's main() function, unlike
157  userland where start code executes .ctors/.dtors before main().  The hardcoded
158  sequence of various subsystem initializations in init_main.c:main() will be
159  replaced by an array of .kctors invocations, and #ifdef's there will be gone.
160
161o Hide link-set in the final kernel.
162
163  Link-set is used to collect references (pointers) at link time.  It relys on
164  the ld(1) behavior that it automatically generates `__start_X' and `__stop_X'
165  symbols for the section `X' to reduce coding.
166
167  Don't allow kernel subsystems create random ELF sections.
168
169  Pre-define all the available link-set names and pre-generate a linker script
170  to merge them into .rodata.
171
172  (For modular(9) modules, `link_set_modules' is looked up by kernel loader.
173  Provide only it.)
174
175  Provide a way for 3rd party modules to declare extra link-set.
176
177o Shared kernel objects.
178
179  Since NetBSD has not established a clear kernel ABI, every single kernel
180  has to build all the objects by their own.  As a result, similar kernels
181  (e.g. evbarm kernels) repeatedly compile similar objects, that is waste of
182  energy & space.
183
184  Share them if possible.  For evb* ports, ideally everything except machdep.ko
185  should be shared.
186
187  While leaving optimizations as options (CPU specific optimizations, inlined
188  bus_space(9) operations, etc.) for users, the official binaries build
189  provided by TNF should be as portable as possible.
190
191o Control ELF sections using linker script.
192
193  Now kernel is linked and built directly from object files (*.o).  Each port
194  has an MD linker script, which does everything needed to be done at link
195  time.  As a result, they do from MI alignment restriction (read_mostly,
196  cacheline_aligned) to load address specification for external boot loaders.
197
198  Make this into multiple stages to make linkage more structural.  Especially,
199  reserve the final link for purely MD purpose.  Note that in modular build,
200  *.ko are shared between build of kernel and modular(9) modules (*.kmod).
201
202	Monolithic build:
203		     *.o  ---> netbsd.ko	Generic MI linkage
204		netbsd.ko ---> netbsd.ro	Kernel MI linkage
205		netbsd.ro ---> netbsd		Kernel MD linkage
206
207	Modular build (kernel):
208		     *.o  --->      *.ko	Generic + Per-module MI linkage
209		     *.ko ---> netbsd.ro	Kernel MI linkage
210		netbsd.ro ---> netbsd		Kernel MD linkage
211
212	Modular build (module):
213		     *.o  --->      *.ko	Generic + Per-module MI linkage
214		     *.ko --->      *.ro	Modular MI linkage
215		     *.ro --->      *.kmod	Modular MD linkage
216
217  Genric MI linkage is for processing MI linkage that can be applied generally.
218  Data section alignment (.data.read_mostly and .data.cacheline_aligned) is
219  processed here.
220
221  Per-module MI linkage is for modules that want some ordering.  For example,
222  machdep.ko wants to put entry code at the top of .text and .data.
223
224  Kernel MI linkage is for collecting kernel global section data, that is what
225  link-set is used for now.  Once they are collected and symbols to the ranges
226  are assigned, those sections are merged into the pre-existing sections
227  (.rodata) because link-set sections in "netbsd" will never be interpreted by
228  external loaders.
229
230  Kernel MD linkage is used purely for MD purposes, that is, how kernels are
231  loaded by external loaders.  It might be possible that one kernel relocatable
232  (netbsd.ro) is linked into multiple final kernel image (netbsd) for diferent
233  load addresses.
234
235  Modular MI linkage is to prepare a module to be loadable as modular(9).  This
236  may add some extra sections and/or symbols.
237
238  Modular MD linkage is again for pure MD purposes like kernel MD linkage.
239  Adjustment and/or optimization may be done.
240
241  Kernel and modular MI linkages may change behavior depending on existence
242  of debug information.  In the future .symtab will be copied using linker
243  during this stage.
244