Return to TODO.modules CVS log

Up to [cvs.NetBSD.org] / src / doc

Annotation of src/doc/TODO.modules, Revision 1.4.2.3

1.4.2.3 ! pgoyette    1: /* $NetBSD$ */
1.4.2.2   pgoyette    2:
                      3: Some notes on the limitations of our current (as of 7.99.35) module
                      4: subsystem.  This list was triggered by an Email exchange between
                      5: christos and pgoyette.
                      6:
1.4.2.3 ! pgoyette    7:  1. Builtin drivers can't depend on modularized drivers (the modularized
        !             8:     drivers are attempted to load as builtins).
1.4.2.2   pgoyette    9:
                     10:        The assumption is that dependencies are loaded before those
                     11:        modules which depend on them.  At load time, a module's
                     12:        undefined global symbols are resolved;  if any symbols can't
                     13:        be resolved, the load fails.  Similarly, if a module is
                     14:        included in (built-into) the kernel, all of its symbols must
                     15:        be resolvable by the linker, otherwise the link fails.
                     16:
                     17:        There are ways around this (such as, having the parent
                     18:        module's initialization command recursively call the module
                     19:        load code), but they're gross hacks.
                     20:
1.4.2.3 ! pgoyette   21:  2. Currently, config(1) has no way to "no define" drivers
        !            22:        XXX: I don't think this is true anymore. I think we can
        !            23:        undefine drivers now, see MODULAR in amd64, which does
        !            24:        no ath* and no select sppp*
        !            25:
        !            26:  3. It is not always obvious by their names which drivers/options
        !            27:     correspond to which modules.
        !            28:
        !            29:  4. Right now critical drivers that would need to be pre-loaded (ffs,
        !            30:     exec_elf64) are still built-in so that we don't need to alter the boot
        !            31:     blocks to boot.
1.4.2.2   pgoyette   32:
                     33:        This was a conscious decision by core@ some years ago.  It is
                     34:        not a requirement that ffs or exec_* be built-in.  The only
                     35:        requirement is that the root file-system's module must be
                     36:        available when the module subsystem is initialized, in order
                     37:        to load other modules.  This can be accomplished by having the
                     38:        boot loader "push" the module at boot time.  (It used to do
                     39:        this in all cases; currently the "push" only occurs if the
                     40:        booted filesystem is not ffs.)
                     41:
1.4.2.3 ! pgoyette   42:  5. Not all parent bus drivers are capable of rescan, so some drivers
        !            43:     just have to be built-in.
1.4.2.2   pgoyette   44:
1.4.2.3 ! pgoyette   45:  6. Many (most?) drivers are not yet modularized
1.4.2.2   pgoyette   46:
1.4.2.3 ! pgoyette   47:  7. There's currently no provisions for autoconfig to figure out which
        !            48:     modules are needed, and thus to load the required modules.
1.4.2.2   pgoyette   49:
                     50:        In the "normal" built-in world, autoconfigure can only ask
                     51:        existing drivers if they're willing to manage (ie, attach) a
                     52:        device.  Removing the built-in drivers tends to limit the
                     53:        availability of possible managers.  There's currently no
                     54:        mechanism for identifying and loading drivers based on what
                     55:        devices might be found.
                     56:
1.4.2.3 ! pgoyette   57:  8. Even for existing modules, there are "surprise" dependencies with
        !            58:     code that has not yet been modularized.
1.4.2.2   pgoyette   59:
                     60:        For example, even though the bpf code has been modularized,
                     61:        there is some shared code in bpf_filter.c which is needed by
                     62:        both ipfilter and ppp.  ipf is already modularized, but ppp
                     63:        is not.  Thus, even though bpf_filter is modular, it MUST be
                     64:        included as a built-in module if you also have ppp in your
                     65:        configuration.
                     66:
                     67:        Another example is sysmon_taskq module.  It is required by
                     68:        other parts of the sysmon subsystem, including the
                     69:        "sysmon_power" module.  Unfortunately, even though the
                     70:        sysmon_power code is modularized, it is referenced by the
                     71:        acpi code which has not been modularized.  Therefore, if your
                     72:        configuration has acpi, then you must include the "sysmon_power"
                     73:        module built-in the kernel.  And therefore your also need to
                     74:        have "sysmon_taskq" and "sysmon" built-in since "sysmon_power"
                     75:        rerefences them.
                     76:
1.4.2.3 ! pgoyette   77:  9. As a corollary to #8 above, having dependencies on modules from code
        !            78:     which has not been modularized makes it extremely difficult to test
        !            79:     the module code adequately.  Testing of module code should include
        !            80:     both testing-as-a-built-in module and testing-as-a-loaded-module, and
        !            81:     all dependencies need to be identified.
        !            82:
        !            83: 10. The current /stand/$ARCH/$VERSION/modules/ hierarchy won't scale as
        !            84:     we get more and more modules.  There are hundreds of potential device
        !            85:     driver modules.
        !            86:
        !            87: 11. There currently isn't any good way to handle attachment-specific
        !            88:     modules.  The build infrastructure (ie, sys/modules/Makefile) doesn't
        !            89:     readily lend itself to bus-specific modules irrespective of $ARCH,
        !            90:     and maintaining distrib/sets/lists/modules/* is awkward at best.
        !            91:
        !            92:     Furthermore, devices such as ld(4), which can attach to a large set
        !            93:     of parent devices, need to be modified.  The parent devices need to
        !            94:     provide a common attribute (for example, ld_bus), and the ld driver
        !            95:     should attach to that attribute rather than to each parent.  But
        !            96:     currently, config(1) doesn't handle this - it doesn't allow an
        !            97:     attribute to be used as the device tree's pseudo-root. The current
        !            98:     directory structure where driver foo is split between ic/foo.c
        !            99:     and bus1/foo_bus1.c ... busn/foo_busn.c is annoying. It would be
        !           100:     better to switch to the FreeBSD model which puts all the driver
        !           101:     files in one directory.
1.4.2.2   pgoyette  102:
1.4.2.3 ! pgoyette  103: 12. Item #11 gets even murkier when a particular parent can provide more
        !           104:     than one attribute.