This is a trade off between two conflicting requirements. If a module
fails during initialization then we want the module symbols to debug
the module. But those same symbols should not be considered valid when
doing insmod. The query_module() interface does not have the
flexibility to distinguish between the two types of user space query.
In any case the problem is bigger than module symbols. What happens
when a module_init breaks after registering some functions? The
functions are registered and can be called, but the module is stuffed.
insmod symbols are just one instance of the wider problem - if a module
fails during init or exit and does not recover then the kernel is in an
unreliable state. It is broken, you get to keep the pieces.
On my todo list for modutils 2.5 is to invoke init_module() from a
separate task. That task will be killed by the kernel oops (there is
no way for userspace to recover from oops) but the parent insmod will
detect the failure and say
init_module() for foo failed. The kernel is in an unreliable state.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/