| @@ -99,35 +99,54 @@ o Introduce "class". | | | @@ -99,35 +99,54 @@ o Introduce "class". |
99 | | | 99 | |
100 | For syntax clarity, class names could be used as a keyword to select the | | 100 | For syntax clarity, class names could be used as a keyword to select the |
101 | class's instance module: | | 101 | class's instance module: |
102 | | | 102 | |
103 | # Define net80211 module as netproto class | | 103 | # Define net80211 module as netproto class |
104 | class netproto | | 104 | class netproto |
105 | define net80211: netproto | | 105 | define net80211: netproto |
106 | | | 106 | |
107 | # Select net80211 to be builtin | | 107 | # Select net80211 to be builtin |
108 | netproto net80211 | | 108 | netproto net80211 |
109 | | | 109 | |
110 | Accordingly device/attach selection syntax should be revisited. | | 110 | Accordingly device/attach selection syntax should be revisited. |
111 | | | 111 | |
112 | o Support kernel constructor/destructor (.ctors/.dtors) | | 112 | o Support kernel constructor/destructor (.kctors/.kdtors) |
113 | | | 113 | |
114 | Initialization and finalization should be called via constructors and | | 114 | Initialization and finalization should be called via constructors and |
115 | destructors. Don't hardcode those sequences as sys/kern/init_main.c:main() | | 115 | destructors. Don't hardcode those sequences as sys/kern/init_main.c:main() |
116 | does. | | 116 | does. |
117 | | | 117 | |
118 | The order of .ctors/.dtors is resolved by dependency. The difference from | | 118 | The order of .kctors/.kdtors is resolved by dependency. The difference from |
119 | userland is that in kernel depended ones are located in lower addresses; | | 119 | userland is that in kernel depended ones are located in lower addresses; |
120 | "machdep" module is the lowest. Thus the lowest entry in .ctors must be | | 120 | "machdep" module is the lowest. Thus the lowest entry in .ctors must be |
121 | executed the first. | | 121 | executed the first. |
122 | | | 122 | |
| | | 123 | The .kctors/.kdtors entries are executed by kernel's main() function, unlike |
| | | 124 | userland where start code executes .ctors/.dtors before main(). The hardcoded |
| | | 125 | sequence of various subsystem initializations in init_main.c:main() will be |
| | | 126 | replaced by an array of .kctors invocaions, and #ifdef's there will be gone. |
| | | 127 | |
123 | o Replace linkset. | | 128 | o Replace linkset. |
124 | | | 129 | |
125 | Don't allow kernel subsystems create random ELF sections (with potentially | | 130 | Don't allow kernel subsystems create random ELF sections (with potentially |
126 | long names) in the final kernel. To collect some data in statically linked | | 131 | long names) in the final kernel. To collect some data in statically linked |
127 | modules, creating intermediate sections (e.g. .data.linkset.sysctl) and | | 132 | modules, creating intermediate sections (e.g. .data.linkset.sysctl) and |
128 | exporting the start/end symbols (e.g. _data_linkset_sysctl_{start,end}) | | 133 | exporting the start/end symbols (e.g. _data_linkset_sysctl_{start,end}) |
129 | using linker script should be fine. | | 134 | using linker script should be fine. |
130 | | | 135 | |
131 | Dynamically loaded modules have to register those entries via constructors | | 136 | Dynamically loaded modules have to register those entries via constructors |
132 | (functions). This means that dynamically loaded modules are flexible but | | 137 | (functions). This means that dynamically loaded modules are flexible but |
133 | come with overhead. | | 138 | come with overhead. |
| | | 139 | |
| | | 140 | o Shared kernel objects. |
| | | 141 | |
| | | 142 | Since NetBSD has not established a clear kernek ABI, every single kernel |
| | | 143 | has to build all the objects by their own. As a result, similar kernels |
| | | 144 | (e.g. evbarm kernels) repeatedly compile similar objects, that is waste of |
| | | 145 | energy & space. |
| | | 146 | |
| | | 147 | Share them if possible. For evb* ports, ideally everything except machdep.ko |
| | | 148 | should be shared. |
| | | 149 | |
| | | 150 | While leaving optimizations as options (CPU specific optimizations, inlined |
| | | 151 | bus_space(9) operations, etc.) for users, the official binaries build |
| | | 152 | provided by TNF should be as portable as possible. |