TODO revision 1.8
11.5Suebayasio Call module as module. 21.5Suebayasi 31.5Suebayasi Until now, everything is called as attribute. Separate module from it: 41.5Suebayasi 51.5Suebayasi - Module is a collection of code (*.[cSo]), and provides a function. 61.5Suebayasi Module can depend on other modules. 71.5Suebayasi 81.5Suebayasi - Attribute provides metadata for modules. One module can have 91.5Suebayasi multiple attributes. Attribute doesn't generate a module (*.o, 101.5Suebayasi *.ko). 111.5Suebayasi 121.1Suebayasio Emit everything (ioconf.*, Makefile, ...) per-attribute. 131.1Suebayasi 141.1Suebayasio Generate modular(9) related information. Especially module dependency. 151.1Suebayasi 161.1Suebayasio Rename "interface attribute" to "bus". 171.1Suebayasi 181.1Suebayasi Instead of 191.1Suebayasi 201.1Suebayasi define audiobus {} 211.1Suebayasi attach audio at audiobus 221.1Suebayasi 231.1Suebayasi Do like this 241.1Suebayasi 251.1Suebayasi defbus audiobus {} 261.1Suebayasi attach audio at audiobus 271.1Suebayasi 281.8Suebayasio Retire "attach foo at bar with foo_bar.c" 291.8Suebayasi 301.8Suebayasi Most of these should be rewritten by defining a common interface attribute 311.8Suebayasi "foobus", instead of writing multiple attachments. com(4), ld(4), ehci(4) 321.8Suebayasi are typical examples. For ehci(4), EHCI-capable controller drivers implement 331.8Suebayasi "ehcibus" interface, like: 341.8Suebayasi 351.8Suebayasi defne ehcibus {} 361.8Suebayasi device imxehci: ehcibus 371.8Suebayasi 381.8Suebayasi These drivers' attach functions call config_found() to attach ehci(4) via 391.8Suebayasi the "ehcibus" interface attribute, instead of calling ehci_init() directly. 401.8Suebayasi Same for com(4) (com_attach_subr()) and ld(4) (ldattach()). 411.8Suebayasi 421.1Suebayasio Sort objects in more reasonable order. 431.1Suebayasi 441.1Suebayasi Put machdep.ko in the lowest address. uvm.ko and kern.ko follow. 451.1Suebayasi 461.1Suebayasi Kill alphabetical sort (${OBJS:O} in sys/conf/Makefile.inc.kern. 471.1Suebayasi 481.1Suebayasi Use ldscript. Do like this 491.1Suebayasi 501.1Suebayasi .text : 511.1Suebayasi AT (ADDR(.text) & 0x0fffffff) 521.1Suebayasi { 531.1Suebayasi *(.text.machdep.locore.entry) 541.1Suebayasi *(.text.machdep.locore) 551.1Suebayasi *(.text.machdep) 561.1Suebayasi *(.text) 571.1Suebayasi *(.text.*) 581.1Suebayasi : 591.1Suebayasi 601.1Suebayasi Kill linker definitions in sys/conf/Makefile.inc.kern. 611.2Suebayasi 621.3Swizo Differentiate "options" and "flags"/"params". 631.2Suebayasi 641.3Swiz "options" enables features by adding *.c files (via attributes). 651.2Suebayasi 661.2Suebayasi "flags" and "params" are to change contents of *.c files. These don't add 671.3Swiz *.c files to the result kernel, or don't build attributes (modules). 681.2Suebayasi 691.2Suebayasio Make flags/params per attributes (modules). 701.2Suebayasi 711.2Suebayasi Basically flags and params are cpp(1) #define's generated in opt_*.h. Make 721.2Suebayasi them local to one attributes (modules). Flags/params which affects files 731.2Suebayasi across attributes (modules) are possible, but should be discouraged. 741.2Suebayasi 751.2Suebayasio Generate things only by definitions. 761.2Suebayasi 771.2Suebayasi In the ideal dynamically modular world, "selection" will be done not at 781.2Suebayasi compile time but at runtime. Users select their wanted modules, by 791.2Suebayasi dynamically loading them. 801.2Suebayasi 811.2Suebayasi This means that the system provides all choices; that is, build all modules 821.2Suebayasi in the source tree. Necessary information is defined in the "definition" 831.2Suebayasi part. 841.2Suebayasi 851.2Suebayasio Split cfdata. 861.2Suebayasi 871.8Suebayasi cfdata is a set of pattern matching rules to enable devices at runtime device 881.3Swiz auto-configuration. It is pure data and can (should) be generated separately 891.2Suebayasi from the code. 901.4Sapb 911.4Sapbo Allow easier adding and removing of options. 921.4Sapb 931.4Sapb It should be possible to add or remove options, flags, etc., 941.4Sapb without regard to whether or not they are already defined. 951.4Sapb For example, a configuration like this: 961.4Sapb 971.4Sapb include GENERIC 981.4Sapb options FOO 991.4Sapb no options BAR 1001.4Sapb 1011.4Sapb should work regardless of whether or not options FOO and/or 1021.4Sapb options BAR were defined in GENERIC. It should not give 1031.4Sapb errors like "options BAR was already defined" or "options FOO 1041.4Sapb was not defined". 1051.4Sapb 1061.5Suebayasio Introduce "class". 1071.5Suebayasi 1081.7Swiz Every module should be classified as at least one class, as modular(9) 1091.7Swiz modules already do. For example, file systems are marked as "vfs", network 1101.5Suebayasi protocols are "netproto". 1111.5Suebayasi 1121.5Suebayasi Consider to merge "devclass" into "class". 1131.5Suebayasi 1141.5Suebayasi For syntax clarity, class names could be used as a keyword to select the 1151.5Suebayasi class's instance module: 1161.5Suebayasi 1171.5Suebayasi # Define net80211 module as netproto class 1181.5Suebayasi class netproto 1191.5Suebayasi define net80211: netproto 1201.5Suebayasi 1211.5Suebayasi # Select net80211 to be builtin 1221.5Suebayasi netproto net80211 1231.5Suebayasi 1241.5Suebayasi Accordingly device/attach selection syntax should be revisited. 1251.5Suebayasi 1261.6Suebayasio Support kernel constructor/destructor (.kctors/.kdtors) 1271.5Suebayasi 1281.5Suebayasi Initialization and finalization should be called via constructors and 1291.5Suebayasi destructors. Don't hardcode those sequences as sys/kern/init_main.c:main() 1301.5Suebayasi does. 1311.5Suebayasi 1321.6Suebayasi The order of .kctors/.kdtors is resolved by dependency. The difference from 1331.5Suebayasi userland is that in kernel depended ones are located in lower addresses; 1341.5Suebayasi "machdep" module is the lowest. Thus the lowest entry in .ctors must be 1351.5Suebayasi executed the first. 1361.5Suebayasi 1371.6Suebayasi The .kctors/.kdtors entries are executed by kernel's main() function, unlike 1381.6Suebayasi userland where start code executes .ctors/.dtors before main(). The hardcoded 1391.6Suebayasi sequence of various subsystem initializations in init_main.c:main() will be 1401.7Swiz replaced by an array of .kctors invocations, and #ifdef's there will be gone. 1411.6Suebayasi 1421.5Suebayasio Replace linkset. 1431.5Suebayasi 1441.5Suebayasi Don't allow kernel subsystems create random ELF sections (with potentially 1451.5Suebayasi long names) in the final kernel. To collect some data in statically linked 1461.5Suebayasi modules, creating intermediate sections (e.g. .data.linkset.sysctl) and 1471.5Suebayasi exporting the start/end symbols (e.g. _data_linkset_sysctl_{start,end}) 1481.5Suebayasi using linker script should be fine. 1491.5Suebayasi 1501.5Suebayasi Dynamically loaded modules have to register those entries via constructors 1511.5Suebayasi (functions). This means that dynamically loaded modules are flexible but 1521.5Suebayasi come with overhead. 1531.6Suebayasi 1541.6Suebayasio Shared kernel objects. 1551.6Suebayasi 1561.7Swiz Since NetBSD has not established a clear kernel ABI, every single kernel 1571.6Suebayasi has to build all the objects by their own. As a result, similar kernels 1581.6Suebayasi (e.g. evbarm kernels) repeatedly compile similar objects, that is waste of 1591.6Suebayasi energy & space. 1601.6Suebayasi 1611.6Suebayasi Share them if possible. For evb* ports, ideally everything except machdep.ko 1621.6Suebayasi should be shared. 1631.6Suebayasi 1641.6Suebayasi While leaving optimizations as options (CPU specific optimizations, inlined 1651.6Suebayasi bus_space(9) operations, etc.) for users, the official binaries build 1661.6Suebayasi provided by TNF should be as portable as possible. 167