The mapping from kernel (binary) to module is generated on-demand right now, because Plugsched doesn't take the responsibility of managing extracted module code.
However, there is indeed the need to build a standardized method to manage it, when the user must maintain many versions of kernels and their corresponding scheduler modules.
One basic observation is that, given two similar kernel binaries, Plugsched yields similar scheduler module sources. This throws some light on how to manage modules. One seemingly feasible idea is to maintain one base version of scheduler module source. Other versions of scheduler module source can be maintained as another branch.
The mapping from kernel (binary) to module is generated on-demand right now, because Plugsched doesn't take the responsibility of managing extracted module code.
However, there is indeed the need to build a standardized method to manage it, when the user must maintain many versions of kernels and their corresponding scheduler modules.
One basic observation is that, given two similar kernel binaries, Plugsched yields similar scheduler module sources. This throws some light on how to manage modules. One seemingly feasible idea is to maintain one base version of scheduler module source. Other versions of scheduler module source can be maintained as another branch.