Home | History | Annotate | Download | only in doc

Lines Matching refs:modules

1 /* $NetBSD: TODO.modules,v 1.24 2021/08/09 20:49:08 andvar Exp $ */
11 	modules which depend on them.  At load time, a module's
22 	"registration" mechanism for the "child" modules, and then when
34     correspond to which modules.
44 	to load other modules.  This can be accomplished by having the
55     modules are needed, and thus to load the required modules.
64  8. Even for existing modules, there are "surprise" dependencies with
84  9. As a corollary to #8 above, having dependencies on modules from code
90 10. The current /stand/$ARCH/$VERSION/modules/ hierarchy won't scale as
91     we get more and more modules.  There are hundreds of potential device
92     driver modules.
95     modules.  The build infrastructure (ie, sys/modules/Makefile) doesn't
96     readily lend itself to bus-specific modules irrespective of $ARCH,
97     and maintaining distrib/sets/lists/modules/* is awkward at best.
116     painful to need to maintain individual architectures' modules/md_*
118     build of the modules based on architecture.  If we had a single
120     select which modules to build and which modules from modules/mi to
125     modules in a version-specific subdirectory of /stand is sub-optimal
127     associating a kernel and its modules needs to be developed.  Some
129     kernel and its modules at /netbsd/kernel and /netbsd/modules/...
136     default module path,  i.e. /stand/$MACHINE/$ALT-RELEASE/modules/
144     Subject: Core statement on directory naming for kernel modules
151        to allow a kernel and its modules to be kept together.
160     does not apply for modules, and instead we need to manually manage
163     other modules on which a module depends.  We really need a common
164     mechanism to define and build modules, whether they are included as
165     "built-in" modules or as separately-loadable modules.
171     be able to search the modules directory for an "appropriate" module
174 16. PR kern/52821 exposes another limitation of config(1) WRT modules.
216 22. A fairly large number of modules still require a maximum warning
223 23. The current process of "load all the emulation/exec modules in case
226     a whole bunch of modules, involving file-system access, just to have
227     most of the modules getting unloaded a few seconds later.  We don't
233     building xen-variant modules (on amd4, and likely i386).  In some
243     been enabled for i386 and amd64 compat_60 modules.