Currently, the naming convention to store one 'version' of a kernel on disk is linux-<version>_<arch>. When custom modules come into play one may want the same kernel version built with different custom modules or arguments.
For custom modules one could just append the parent directory of where the included modules are included from, e.g.: linux-<version>_<arch>_<echo_service>.
As for different configurations of the same kernel version this method does not hold.
So maybe another sanity check that checks for a .likedbg_config within the kernel root for the requested Kernel parameters. If they do not match we need a new freshly unpacked version and with that, an updated kernel root.
However, placing this check in the kernel builder is too late, as control flow may need to be redirected back to the unpacker...
Currently, the naming convention to store one 'version' of a kernel on disk is
linux-<version>_<arch>
. When custom modules come into play one may want the same kernel version built with different custom modules or arguments. For custom modules one could just append the parent directory of where the included modules are included from, e.g.:linux-<version>_<arch>_<echo_service>
. As for different configurations of the same kernel version this method does not hold. So maybe another sanity check that checks for a.likedbg_config
within the kernel root for the requested Kernel parameters. If they do not match we need a new freshly unpacked version and with that, an updated kernel root. However, placing this check in the kernel builder is too late, as control flow may need to be redirected back to the unpacker...