Home | History | Annotate | Line # | Download | only in config
TODO revision 1.7 
      1 o 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 
     12 o Emit everything (ioconf.*, Makefile, ...) per-attribute.
     13 
     14 o Generate modular(9) related information.  Especially module dependency.
     15 
     16 o Rename "interface attribute" to "bus".
     17 
     18   Instead of
     19 
     20 	define	audiobus {}
     21 	attach	audio at audiobus
     22 
     23   Do like this
     24 
     25 	defbus	audiobus {}
     26 	attach	audio at audiobus
     27 
     28 o Sort objects in more reasonable order.
     29 
     30   Put machdep.ko in the lowest address.  uvm.ko and kern.ko follow.
     31 
     32   Kill alphabetical sort (${OBJS:O} in sys/conf/Makefile.inc.kern.
     33 
     34   Use ldscript.  Do like this
     35 
     36 	.text :
     37 	AT (ADDR(.text) & 0x0fffffff)
     38 	{
     39 	  *(.text.machdep.locore.entry)
     40 	  *(.text.machdep.locore)
     41 	  *(.text.machdep)
     42 	  *(.text)
     43 	  *(.text.*)
     44 	  :
     45 
     46   Kill linker definitions in sys/conf/Makefile.inc.kern.
     47 
     48 o Differentiate "options" and "flags"/"params".
     49 
     50   "options" enables features by adding *.c files (via attributes).
     51 
     52   "flags" and "params" are to change contents of *.c files.  These don't add
     53   *.c files to the result kernel, or don't build attributes (modules).
     54 
     55 o Make flags/params per attributes (modules).
     56 
     57   Basically flags and params are cpp(1) #define's generated in opt_*.h.  Make
     58   them local to one attributes (modules).  Flags/params which affects files
     59   across attributes (modules) are possible, but should be discouraged.
     60 
     61 o Generate things only by definitions.
     62 
     63   In the ideal dynamically modular world, "selection" will be done not at
     64   compile time but at runtime.  Users select their wanted modules, by
     65   dynamically loading them.
     66 
     67   This means that the system provides all choices; that is, build all modules
     68   in the source tree.  Necessary information is defined in the "definition"
     69   part.
     70 
     71 o Split cfdata.
     72 
     73   cfdata is pattern matching rules to enable devices at runtime device
     74   auto-configuration.  It is pure data and can (should) be generated separately
     75   from the code.
     76 
     77 o Allow easier adding and removing of options.
     78 
     79   It should be possible to add or remove options, flags, etc.,
     80   without regard to whether or not they are already defined.
     81   For example, a configuration like this:
     82 
     83 	include GENERIC
     84 	options FOO
     85 	no options BAR
     86 
     87   should work regardless of whether or not options FOO and/or
     88   options BAR were defined in GENERIC.  It should not give
     89   errors like "options BAR was already defined" or "options FOO
     90   was not defined".
     91 
     92 o Introduce "class".
     93 
     94   Every module should be classified as at least one class, as modular(9)
     95   modules already do.  For example, file systems are marked as "vfs", network
     96   protocols are "netproto".
     97 
     98   Consider to merge "devclass" into "class".
     99 
    100   For syntax clarity, class names could be used as a keyword to select the
    101   class's instance module:
    102 
    103 	# Define net80211 module as netproto class
    104 	class netproto
    105 	define net80211: netproto
    106 
    107 	# Select net80211 to be builtin
    108 	netproto net80211
    109 
    110   Accordingly device/attach selection syntax should be revisited.
    111 
    112 o Support kernel constructor/destructor (.kctors/.kdtors)
    113 
    114   Initialization and finalization should be called via constructors and
    115   destructors.  Don't hardcode those sequences as sys/kern/init_main.c:main()
    116   does.
    117 
    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;
    120   "machdep" module is the lowest.  Thus the lowest entry in .ctors must be
    121   executed the first.
    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 invocations, and #ifdef's there will be gone.
    127 
    128 o Replace linkset.
    129 
    130   Don't allow kernel subsystems create random ELF sections (with potentially
    131   long names) in the final kernel.  To collect some data in statically linked
    132   modules, creating intermediate sections (e.g. .data.linkset.sysctl) and
    133   exporting the start/end symbols (e.g. _data_linkset_sysctl_{start,end})
    134   using linker script should be fine.
    135 
    136   Dynamically loaded modules have to register those entries via constructors
    137   (functions).  This means that dynamically loaded modules are flexible but
    138   come with overhead.
    139 
    140 o Shared kernel objects.
    141 
    142   Since NetBSD has not established a clear kernel 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.
    153