This may end up being useful in the distro patch module upgrade path.
If the core module also needs updating, we can first do "kpatch unload
--all" and "rmmod kpatch" before doing "kpatch load" of the new patch
module.
The user-installed vs system-installed dichotomy is confusing. Let's
just have "installed". RPM-installed modules can just call "kpatch
install" in their post-install step.
Allow the user to atomically replace all existing modules with a new
"kpatch replace" command. This provides a safe way to do atomic
upgrades for cumulative patch module updates.
A user may want to load a module without having to install it to the
initrd. In fact, 99% of the time I think that will be the typical usage
of "kpatch load", with a given file as an argument rather than a DB
module.
Have "kpatch load" and other commands take a file as input. If the file
is not found, then check the DB.
Try to be more consistent with the terminology. In various places we
call it a "hotpatch module", "hot patch module", or "patch module". How
about we just call it a "patch module" everywhere?
After removing the distinction between 'enabled' modules and 'applied'
modules in 022e42bc, we can change the 'apply' and 'remove' subcommands,
to more intuitive 'load' and 'unload' subcommands.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
