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 ...
fs/buffer.c:module_init(bdflush_init)
fs/pipe.c:module_init(init_pipe_fs)
fs/fcntl.c:module_init(fasync_init)
fs/locks.c:module_init(filelock_init)
fs/dnotify.c:module_init(dnotify_init)
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 vmlinux.lds 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/