Home | History | Annotate | Line # | Download | only in config
TODO revision 1.8
      1  1.5  uebayasi o Call module as module.
      2  1.5  uebayasi 
      3  1.5  uebayasi   Until now, everything is called as attribute.  Separate module from it:
      4  1.5  uebayasi 
      5  1.5  uebayasi 	- Module is a collection of code (*.[cSo]), and provides a function.
      6  1.5  uebayasi 	  Module can depend on other modules.
      7  1.5  uebayasi 
      8  1.5  uebayasi 	- Attribute provides metadata for modules.  One module can have
      9  1.5  uebayasi 	  multiple attributes.  Attribute doesn't generate a module (*.o,
     10  1.5  uebayasi 	  *.ko).
     11  1.5  uebayasi 
     12  1.1  uebayasi o Emit everything (ioconf.*, Makefile, ...) per-attribute.
     13  1.1  uebayasi 
     14  1.1  uebayasi o Generate modular(9) related information.  Especially module dependency.
     15  1.1  uebayasi 
     16  1.1  uebayasi o Rename "interface attribute" to "bus".
     17  1.1  uebayasi 
     18  1.1  uebayasi   Instead of
     19  1.1  uebayasi 
     20  1.1  uebayasi 	define	audiobus {}
     21  1.1  uebayasi 	attach	audio at audiobus
     22  1.1  uebayasi 
     23  1.1  uebayasi   Do like this
     24  1.1  uebayasi 
     25  1.1  uebayasi 	defbus	audiobus {}
     26  1.1  uebayasi 	attach	audio at audiobus
     27  1.1  uebayasi 
     28  1.8  uebayasi o Retire "attach foo at bar with foo_bar.c"
     29  1.8  uebayasi 
     30  1.8  uebayasi   Most of these should be rewritten by defining a common interface attribute
     31  1.8  uebayasi   "foobus", instead of writing multiple attachments.  com(4), ld(4), ehci(4)
     32  1.8  uebayasi   are typical examples.  For ehci(4), EHCI-capable controller drivers implement
     33  1.8  uebayasi   "ehcibus" interface, like:
     34  1.8  uebayasi 
     35  1.8  uebayasi 	defne	ehcibus {}
     36  1.8  uebayasi 	device	imxehci: ehcibus
     37  1.8  uebayasi 
     38  1.8  uebayasi   These drivers' attach functions call config_found() to attach ehci(4) via
     39  1.8  uebayasi   the "ehcibus" interface attribute, instead of calling ehci_init() directly.
     40  1.8  uebayasi   Same for com(4) (com_attach_subr()) and ld(4) (ldattach()).
     41  1.8  uebayasi 
     42  1.1  uebayasi o Sort objects in more reasonable order.
     43  1.1  uebayasi 
     44  1.1  uebayasi   Put machdep.ko in the lowest address.  uvm.ko and kern.ko follow.
     45  1.1  uebayasi 
     46  1.1  uebayasi   Kill alphabetical sort (${OBJS:O} in sys/conf/Makefile.inc.kern.
     47  1.1  uebayasi 
     48  1.1  uebayasi   Use ldscript.  Do like this
     49  1.1  uebayasi 
     50  1.1  uebayasi 	.text :
     51  1.1  uebayasi 	AT (ADDR(.text) & 0x0fffffff)
     52  1.1  uebayasi 	{
     53  1.1  uebayasi 	  *(.text.machdep.locore.entry)
     54  1.1  uebayasi 	  *(.text.machdep.locore)
     55  1.1  uebayasi 	  *(.text.machdep)
     56  1.1  uebayasi 	  *(.text)
     57  1.1  uebayasi 	  *(.text.*)
     58  1.1  uebayasi 	  :
     59  1.1  uebayasi 
     60  1.1  uebayasi   Kill linker definitions in sys/conf/Makefile.inc.kern.
     61  1.2  uebayasi 
     62  1.3       wiz o Differentiate "options" and "flags"/"params".
     63  1.2  uebayasi 
     64  1.3       wiz   "options" enables features by adding *.c files (via attributes).
     65  1.2  uebayasi 
     66  1.2  uebayasi   "flags" and "params" are to change contents of *.c files.  These don't add
     67  1.3       wiz   *.c files to the result kernel, or don't build attributes (modules).
     68  1.2  uebayasi 
     69  1.2  uebayasi o Make flags/params per attributes (modules).
     70  1.2  uebayasi 
     71  1.2  uebayasi   Basically flags and params are cpp(1) #define's generated in opt_*.h.  Make
     72  1.2  uebayasi   them local to one attributes (modules).  Flags/params which affects files
     73  1.2  uebayasi   across attributes (modules) are possible, but should be discouraged.
     74  1.2  uebayasi 
     75  1.2  uebayasi o Generate things only by definitions.
     76  1.2  uebayasi 
     77  1.2  uebayasi   In the ideal dynamically modular world, "selection" will be done not at
     78  1.2  uebayasi   compile time but at runtime.  Users select their wanted modules, by
     79  1.2  uebayasi   dynamically loading them.
     80  1.2  uebayasi 
     81  1.2  uebayasi   This means that the system provides all choices; that is, build all modules
     82  1.2  uebayasi   in the source tree.  Necessary information is defined in the "definition"
     83  1.2  uebayasi   part.
     84  1.2  uebayasi 
     85  1.2  uebayasi o Split cfdata.
     86  1.2  uebayasi 
     87  1.8  uebayasi   cfdata is a set of pattern matching rules to enable devices at runtime device
     88  1.3       wiz   auto-configuration.  It is pure data and can (should) be generated separately
     89  1.2  uebayasi   from the code.
     90  1.4       apb 
     91  1.4       apb o Allow easier adding and removing of options.
     92  1.4       apb 
     93  1.4       apb   It should be possible to add or remove options, flags, etc.,
     94  1.4       apb   without regard to whether or not they are already defined.
     95  1.4       apb   For example, a configuration like this:
     96  1.4       apb 
     97  1.4       apb 	include GENERIC
     98  1.4       apb 	options FOO
     99  1.4       apb 	no options BAR
    100  1.4       apb 
    101  1.4       apb   should work regardless of whether or not options FOO and/or
    102  1.4       apb   options BAR were defined in GENERIC.  It should not give
    103  1.4       apb   errors like "options BAR was already defined" or "options FOO
    104  1.4       apb   was not defined".
    105  1.4       apb 
    106  1.5  uebayasi o Introduce "class".
    107  1.5  uebayasi 
    108  1.7       wiz   Every module should be classified as at least one class, as modular(9)
    109  1.7       wiz   modules already do.  For example, file systems are marked as "vfs", network
    110  1.5  uebayasi   protocols are "netproto".
    111  1.5  uebayasi 
    112  1.5  uebayasi   Consider to merge "devclass" into "class".
    113  1.5  uebayasi 
    114  1.5  uebayasi   For syntax clarity, class names could be used as a keyword to select the
    115  1.5  uebayasi   class's instance module:
    116  1.5  uebayasi 
    117  1.5  uebayasi 	# Define net80211 module as netproto class
    118  1.5  uebayasi 	class netproto
    119  1.5  uebayasi 	define net80211: netproto
    120  1.5  uebayasi 
    121  1.5  uebayasi 	# Select net80211 to be builtin
    122  1.5  uebayasi 	netproto net80211
    123  1.5  uebayasi 
    124  1.5  uebayasi   Accordingly device/attach selection syntax should be revisited.
    125  1.5  uebayasi 
    126  1.6  uebayasi o Support kernel constructor/destructor (.kctors/.kdtors)
    127  1.5  uebayasi 
    128  1.5  uebayasi   Initialization and finalization should be called via constructors and
    129  1.5  uebayasi   destructors.  Don't hardcode those sequences as sys/kern/init_main.c:main()
    130  1.5  uebayasi   does.
    131  1.5  uebayasi 
    132  1.6  uebayasi   The order of .kctors/.kdtors is resolved by dependency.  The difference from
    133  1.5  uebayasi   userland is that in kernel depended ones are located in lower addresses;
    134  1.5  uebayasi   "machdep" module is the lowest.  Thus the lowest entry in .ctors must be
    135  1.5  uebayasi   executed the first.
    136  1.5  uebayasi 
    137  1.6  uebayasi   The .kctors/.kdtors entries are executed by kernel's main() function, unlike
    138  1.6  uebayasi   userland where start code executes .ctors/.dtors before main().  The hardcoded
    139  1.6  uebayasi   sequence of various subsystem initializations in init_main.c:main() will be
    140  1.7       wiz   replaced by an array of .kctors invocations, and #ifdef's there will be gone.
    141  1.6  uebayasi 
    142  1.5  uebayasi o Replace linkset.
    143  1.5  uebayasi 
    144  1.5  uebayasi   Don't allow kernel subsystems create random ELF sections (with potentially
    145  1.5  uebayasi   long names) in the final kernel.  To collect some data in statically linked
    146  1.5  uebayasi   modules, creating intermediate sections (e.g. .data.linkset.sysctl) and
    147  1.5  uebayasi   exporting the start/end symbols (e.g. _data_linkset_sysctl_{start,end})
    148  1.5  uebayasi   using linker script should be fine.
    149  1.5  uebayasi 
    150  1.5  uebayasi   Dynamically loaded modules have to register those entries via constructors
    151  1.5  uebayasi   (functions).  This means that dynamically loaded modules are flexible but
    152  1.5  uebayasi   come with overhead.
    153  1.6  uebayasi 
    154  1.6  uebayasi o Shared kernel objects.
    155  1.6  uebayasi 
    156  1.7       wiz   Since NetBSD has not established a clear kernel ABI, every single kernel
    157  1.6  uebayasi   has to build all the objects by their own.  As a result, similar kernels
    158  1.6  uebayasi   (e.g. evbarm kernels) repeatedly compile similar objects, that is waste of
    159  1.6  uebayasi   energy & space.
    160  1.6  uebayasi 
    161  1.6  uebayasi   Share them if possible.  For evb* ports, ideally everything except machdep.ko
    162  1.6  uebayasi   should be shared.
    163  1.6  uebayasi 
    164  1.6  uebayasi   While leaving optimizations as options (CPU specific optimizations, inlined
    165  1.6  uebayasi   bus_space(9) operations, etc.) for users, the official binaries build
    166  1.6  uebayasi   provided by TNF should be as portable as possible.
    167