[lkml]   [2001]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Where did vm_operations_struct->unmap in 2.4.0 go?
    On Fri, 12 Jan 2001 10:27:34 +0000 (GMT), 
    David Woodhouse <> wrote:
    >On Fri, 12 Jan 2001, Keith Owens wrote:
    >> A typical graph would have scsi disk depends on scsi host adaptor group
    >> which depends on pci.
    >No. sd will happily take over any existing devices when as and when they
    >arrive. It doesn't have to be loaded last. Likewise, in theory at least,
    >host adaptor drivers using the new PCI driver code would respond correctly
    >to the PCI code being initialised (and calling their ->probe routine)
    >later, although that doesn't happen now.

    You just proved my point. It is extremely difficult to deduce the
    required initialisation order by reading an undocumented Makefile where
    the init order is implemented as a side effect of selection order. The
    existing method implies link order when none is required.

    >> Most of the objects have fairly simple execution dependencies, e.g.
    >> all file systems depend on core fs code having already executed.
    >Er... Why? They call register_filesystem() which uses a lock which is
    >staticly initialised. Don't order stuff for the sake of it. If there are
    >filesystems which _do_ require the VFS to be initialised first, those
    >filesystems can be marked as such. I'm not aware of any.

    I was using scsi and fs as examples, no need to pick holes in the
    examples. But ...


    I'm no filesystem expert but it appears that some of those core
    initialisation routines must be executed before most filesystems can
    start. In particular, filelock_init() must be executed before any
    filesystem that supports locks is initialised.

    >All I want is a way to staticly add entries to the
    >inter_module_xxx tables at compile time, because I _have_ done the
    >analysis, and I'm saying that's when they should be made available.

    Firstly inter_module_xxx is only used by that very small subset of code
    where there are no constraints on whether the caller and callee can be
    in kernel, in modules or a mixture _and_ some of the objects are
    optional. It is a special case because most code handles this problem
    through CONFIG options. If X needs (Y, Z) and X is built into the
    kernel then (Y, Z) must also be built into the kernel. If Y or Z are
    optional then control the calls to those functions with CONFIG options.
    Almost all of the kernel handles it properly though CONFIG, so
    inter_module_xxx is already a process to handle a few special cases.

    Secondly you want static inter_module_xxx tables for a small subset of
    these special cases, where the source has no other initialisation code.
    This is piling special cases on special cases. Adding static
    inter_module_xxx tables requires

    * changes to linux/modules.h to define the new table format and
    * changes to for _every_ architecture to bring all the
    static tables together in vmlinux and
    * new initialisation code in module.c to read and load all the static
    tables at boot time and
    * extra code in modutils to find any static tables in modules and
    * an extension to struct modules to let modutils pass information about
    the static tables to the kernel and
    * the kernel code will only work with an upgraded modutils.

    That is a lot of work for a very few special cases. OTOH, you could
    just swap the order of 3 lines in drivers/mtd/Makefile. Guess which
    alternative I am going for?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:28    [W:0.041 / U:1.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site