Re: Proposal: Disable autoload of compat_xyz modules

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Aug 2,  5:02pm, Martin Husemann wrote:
} On Wed, Aug 02, 2017 at 07:56:50AM -0700, Brian Buhrow wrote:
} > 	Hello.  My feeling is that the cost of requiring a modload to use
} > compat_linux and compat_linux32 is fine.  My concern is that by taking it
} > out of the GENERIC kernel configuration, we lose the regular testing, such
} > as it is, with the daily builds.  Sure, the module gets built, but it could
} > be a while before it gets loaded and run by the test harness.  Today, with
} > these modules in GENERIC, the modules get loaded as a matter of course.
} > Is there a way to rig our test harness so that you can take the modules out
} > of the GENERIC kernel configuration and still do more than compile-time
} > test them?
} 
} The tests exercise quite a few modules, but currently testing compat stuff
} is tricky (due to the extra setup needed on the test machine to have a
} create the compat runtime environment).
} 
} Just doing a few modctl and load some of them is simple, but what does that
} actually buy us?

     Originally, it was my thought that compiling it as a module
and not using it is the same as compiling it into the kernel and
not using it.  However, it is possible to create a module that
fails to load due to run time linking issues.  So, having a test
that does modload ensures that the module can still linked into
the kernel.

}-- End of excerpt from Martin Husemann