Hi Dave,
Thanks for your review and inputs.
On 18/02/2016:08:44:25 PM, Dave Young wrote:
I have several thing to make clear:
* Previously we tried to add it as a dracut module in upstream dracut.
https://www.mail-archive.com/initramfs@vger.kernel.org/msg03299.html
In dracut there is a simple watchdog module which is used for testing purpose
only.
We have a reliable way to get hostonly live watchdog module based on your
kernel patches, so it might be better to retry to enhance the dracut watchdog
module. Kdump use dracut --hostonly, we can add using wdt module for hostonly
mode. In this way we can add another dracut kernel cmdline like rd.nowdt so
that one can disable wdt functionality in initramfs if he/she want the original
behavior.
Its a good idea for implementing a switch, which will help to insert or not to insert
active wdt module in kdump kernel. Since, I do not have much idea about dracut,
so to understand it better for implementation perspective:
- user can pass rd.nowdt through KDUMP_COMMANDLINE_APPEND of
/etc/sysconfig/kdump
- We will have an upstream dracut change, which will check that if rd.nowdt was
*not* passed in command line then, add modules from rd.driver.pre.
* Previously we planned to only enabling wdt when driver initialization can not
stop wdt eg. in 2nd kernel the wdt status is active after insmod. But if we
copy systemd.conf from 1st kernel to initrd, it will by default enable the
wdt. Do you think it is a better way? Maybe it can address the concern from
Prarit?
I think, its better to keep same state of wdt what was in primary kernel (if
rd.nowdt was not passed). I am not sure if we need to implement systemd.conf
copy, I think that is already done currently. Both on fedora and RHEL as you can
see in commit log, wdt is active in kdump kernel if it was active in primary
kernel.
> kdump:/# cat /sys/class/watchdog/watchdog0/state
> active
* What if in 1st kernel one do not use systemd as wdt daemon? Then in 2nd
kernel the behavior will be just like what we planned, insmod, driver stop the
wdt, but still need kick it when driver failed to stop the wdt?
If it is not systemd and a custom wdt application, then I think user will need
to pass name of the application in /etc/kdump.conf:extra_bins and the kick
command in /etc/kdump.conf:kdump_pre.
~Pratyush