TODO revision 1.8 1 1.5 uebayasi o Call module as module.
2 1.5 uebayasi
3 1.5 uebayasi Until now, everything is called as attribute. Separate module from it:
4 1.5 uebayasi
5 1.5 uebayasi - Module is a collection of code (*.[cSo]), and provides a function.
6 1.5 uebayasi Module can depend on other modules.
7 1.5 uebayasi
8 1.5 uebayasi - Attribute provides metadata for modules. One module can have
9 1.5 uebayasi multiple attributes. Attribute doesn't generate a module (*.o,
10 1.5 uebayasi *.ko).
11 1.5 uebayasi
12 1.1 uebayasi o Emit everything (ioconf.*, Makefile, ...) per-attribute.
13 1.1 uebayasi
14 1.1 uebayasi o Generate modular(9) related information. Especially module dependency.
15 1.1 uebayasi
16 1.1 uebayasi o Rename "interface attribute" to "bus".
17 1.1 uebayasi
18 1.1 uebayasi Instead of
19 1.1 uebayasi
20 1.1 uebayasi define audiobus {}
21 1.1 uebayasi attach audio at audiobus
22 1.1 uebayasi
23 1.1 uebayasi Do like this
24 1.1 uebayasi
25 1.1 uebayasi defbus audiobus {}
26 1.1 uebayasi attach audio at audiobus
27 1.1 uebayasi
28 1.8 uebayasi o Retire "attach foo at bar with foo_bar.c"
29 1.8 uebayasi
30 1.8 uebayasi Most of these should be rewritten by defining a common interface attribute
31 1.8 uebayasi "foobus", instead of writing multiple attachments. com(4), ld(4), ehci(4)
32 1.8 uebayasi are typical examples. For ehci(4), EHCI-capable controller drivers implement
33 1.8 uebayasi "ehcibus" interface, like:
34 1.8 uebayasi
35 1.8 uebayasi defne ehcibus {}
36 1.8 uebayasi device imxehci: ehcibus
37 1.8 uebayasi
38 1.8 uebayasi These drivers' attach functions call config_found() to attach ehci(4) via
39 1.8 uebayasi the "ehcibus" interface attribute, instead of calling ehci_init() directly.
40 1.8 uebayasi Same for com(4) (com_attach_subr()) and ld(4) (ldattach()).
41 1.8 uebayasi
42 1.1 uebayasi o Sort objects in more reasonable order.
43 1.1 uebayasi
44 1.1 uebayasi Put machdep.ko in the lowest address. uvm.ko and kern.ko follow.
45 1.1 uebayasi
46 1.1 uebayasi Kill alphabetical sort (${OBJS:O} in sys/conf/Makefile.inc.kern.
47 1.1 uebayasi
48 1.1 uebayasi Use ldscript. Do like this
49 1.1 uebayasi
50 1.1 uebayasi .text :
51 1.1 uebayasi AT (ADDR(.text) & 0x0fffffff)
52 1.1 uebayasi {
53 1.1 uebayasi *(.text.machdep.locore.entry)
54 1.1 uebayasi *(.text.machdep.locore)
55 1.1 uebayasi *(.text.machdep)
56 1.1 uebayasi *(.text)
57 1.1 uebayasi *(.text.*)
58 1.1 uebayasi :
59 1.1 uebayasi
60 1.1 uebayasi Kill linker definitions in sys/conf/Makefile.inc.kern.
61 1.2 uebayasi
62 1.3 wiz o Differentiate "options" and "flags"/"params".
63 1.2 uebayasi
64 1.3 wiz "options" enables features by adding *.c files (via attributes).
65 1.2 uebayasi
66 1.2 uebayasi "flags" and "params" are to change contents of *.c files. These don't add
67 1.3 wiz *.c files to the result kernel, or don't build attributes (modules).
68 1.2 uebayasi
69 1.2 uebayasi o Make flags/params per attributes (modules).
70 1.2 uebayasi
71 1.2 uebayasi Basically flags and params are cpp(1) #define's generated in opt_*.h. Make
72 1.2 uebayasi them local to one attributes (modules). Flags/params which affects files
73 1.2 uebayasi across attributes (modules) are possible, but should be discouraged.
74 1.2 uebayasi
75 1.2 uebayasi o Generate things only by definitions.
76 1.2 uebayasi
77 1.2 uebayasi In the ideal dynamically modular world, "selection" will be done not at
78 1.2 uebayasi compile time but at runtime. Users select their wanted modules, by
79 1.2 uebayasi dynamically loading them.
80 1.2 uebayasi
81 1.2 uebayasi This means that the system provides all choices; that is, build all modules
82 1.2 uebayasi in the source tree. Necessary information is defined in the "definition"
83 1.2 uebayasi part.
84 1.2 uebayasi
85 1.2 uebayasi o Split cfdata.
86 1.2 uebayasi
87 1.8 uebayasi cfdata is a set of pattern matching rules to enable devices at runtime device
88 1.3 wiz auto-configuration. It is pure data and can (should) be generated separately
89 1.2 uebayasi from the code.
90 1.4 apb
91 1.4 apb o Allow easier adding and removing of options.
92 1.4 apb
93 1.4 apb It should be possible to add or remove options, flags, etc.,
94 1.4 apb without regard to whether or not they are already defined.
95 1.4 apb For example, a configuration like this:
96 1.4 apb
97 1.4 apb include GENERIC
98 1.4 apb options FOO
99 1.4 apb no options BAR
100 1.4 apb
101 1.4 apb should work regardless of whether or not options FOO and/or
102 1.4 apb options BAR were defined in GENERIC. It should not give
103 1.4 apb errors like "options BAR was already defined" or "options FOO
104 1.4 apb was not defined".
105 1.4 apb
106 1.5 uebayasi o Introduce "class".
107 1.5 uebayasi
108 1.7 wiz Every module should be classified as at least one class, as modular(9)
109 1.7 wiz modules already do. For example, file systems are marked as "vfs", network
110 1.5 uebayasi protocols are "netproto".
111 1.5 uebayasi
112 1.5 uebayasi Consider to merge "devclass" into "class".
113 1.5 uebayasi
114 1.5 uebayasi For syntax clarity, class names could be used as a keyword to select the
115 1.5 uebayasi class's instance module:
116 1.5 uebayasi
117 1.5 uebayasi # Define net80211 module as netproto class
118 1.5 uebayasi class netproto
119 1.5 uebayasi define net80211: netproto
120 1.5 uebayasi
121 1.5 uebayasi # Select net80211 to be builtin
122 1.5 uebayasi netproto net80211
123 1.5 uebayasi
124 1.5 uebayasi Accordingly device/attach selection syntax should be revisited.
125 1.5 uebayasi
126 1.6 uebayasi o Support kernel constructor/destructor (.kctors/.kdtors)
127 1.5 uebayasi
128 1.5 uebayasi Initialization and finalization should be called via constructors and
129 1.5 uebayasi destructors. Don't hardcode those sequences as sys/kern/init_main.c:main()
130 1.5 uebayasi does.
131 1.5 uebayasi
132 1.6 uebayasi The order of .kctors/.kdtors is resolved by dependency. The difference from
133 1.5 uebayasi userland is that in kernel depended ones are located in lower addresses;
134 1.5 uebayasi "machdep" module is the lowest. Thus the lowest entry in .ctors must be
135 1.5 uebayasi executed the first.
136 1.5 uebayasi
137 1.6 uebayasi The .kctors/.kdtors entries are executed by kernel's main() function, unlike
138 1.6 uebayasi userland where start code executes .ctors/.dtors before main(). The hardcoded
139 1.6 uebayasi sequence of various subsystem initializations in init_main.c:main() will be
140 1.7 wiz replaced by an array of .kctors invocations, and #ifdef's there will be gone.
141 1.6 uebayasi
142 1.5 uebayasi o Replace linkset.
143 1.5 uebayasi
144 1.5 uebayasi Don't allow kernel subsystems create random ELF sections (with potentially
145 1.5 uebayasi long names) in the final kernel. To collect some data in statically linked
146 1.5 uebayasi modules, creating intermediate sections (e.g. .data.linkset.sysctl) and
147 1.5 uebayasi exporting the start/end symbols (e.g. _data_linkset_sysctl_{start,end})
148 1.5 uebayasi using linker script should be fine.
149 1.5 uebayasi
150 1.5 uebayasi Dynamically loaded modules have to register those entries via constructors
151 1.5 uebayasi (functions). This means that dynamically loaded modules are flexible but
152 1.5 uebayasi come with overhead.
153 1.6 uebayasi
154 1.6 uebayasi o Shared kernel objects.
155 1.6 uebayasi
156 1.7 wiz Since NetBSD has not established a clear kernel ABI, every single kernel
157 1.6 uebayasi has to build all the objects by their own. As a result, similar kernels
158 1.6 uebayasi (e.g. evbarm kernels) repeatedly compile similar objects, that is waste of
159 1.6 uebayasi energy & space.
160 1.6 uebayasi
161 1.6 uebayasi Share them if possible. For evb* ports, ideally everything except machdep.ko
162 1.6 uebayasi should be shared.
163 1.6 uebayasi
164 1.6 uebayasi While leaving optimizations as options (CPU specific optimizations, inlined
165 1.6 uebayasi bus_space(9) operations, etc.) for users, the official binaries build
166 1.6 uebayasi provided by TNF should be as portable as possible.
167