On Friday 03 January 2014, Russell King - ARM Linux wrote:

On Fri, Jan 03, 2014 at 01:10:09PM +0100, Arnd Bergmann wrote:

quoted

Aside from the good comments that Russell made, I would remark that the
fact that you need multiple megabytes worth of modules indicates that you
are doing something wrong. Can you point to a git tree containing those
modules?

From the comments which have been made, one point that seems to have
been identified is that if this module is first stripped and then
loaded, it can load, but if it's unstripped, it's too big.  This sounds
suboptimal to me - the debug info shouldn't be loaded into the kernel.

Reading the layout_and_allocate() function, that is probably the
intention already, and if something goes wrong there on ARM, it could be
fixed up in an arch specific module_frob_arch_sections() function.

However, I guess there's bad interactions with module signing if you
don't do this and the module was signed with the debug info present,
so I don't think there's a good solution for this.

My point was another anyway: I can't think of any good reason why
you would end up with this many modules on any sane system. The only
cases I've seen so far are

- modules written in C++, with libstdc++ linked into the module
- a closed-source platform port hidden in a loadable module that
  contains all the device drivers and subsystems while ignoring the
  infrastructure we have in the kernel, and the possible legal
  implications.
- a bug in the module using large arrays that should just be
  dynamically allocated.
- device firmware statically linked into the module rather than
  loaded using request_firmware.

In each of these cases, the real answer is to fix the code they are
trying to load to do things in a more common way, especially if the
intention is to eventually merge the code upstream. It is of course
possible that they are indeed trying something valid, that's why
I asked to see the source code.

	Arnd