Added option signal to man page, under commands, based on usage function in
kpatch/kpatch usage()
Signed-off-by: Sanskriti sharma <sansharm@redhat.com>
Kpatch no longer uses initrd to make sure the patch modules are loaded
at boot. The users could either install the provided systemd service
for that or come up with some other solution.
The messages mentioning initrd could confuse the users.
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
"kpatch replace" is complex, buggy, and probably unnecessary. And
upstream livepatch has nothing like it.
Remove it from the kpatch utility, but leave the infrastructure in place
in the patch module and the core module for now.
Fixes: #456
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>
