Home | History | Annotate | Line # | Download | only in config
TODO revision 1.5 
      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 classfied as at least one class, as modular(9)
     95   modules already do.  For example, filesystems 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 (.ctors/.dtors)
    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 .ctors/.dtors 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 o Replace linkset.
    124 
    125   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
    127   modules, creating intermediate sections (e.g. .data.linkset.sysctl) and
    128   exporting the start/end symbols (e.g. _data_linkset_sysctl_{start,end})
    129   using linker script should be fine.
    130 
    131   Dynamically loaded modules have to register those entries via constructors
    132   (functions).  This means that dynamically loaded modules are flexible but
    133   come with overhead.
    134