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