On 07/03/17 at 02:32pm, Xunlei Pang wrote:
On 07/03/2017 at 01:50 PM, Dave Young wrote:
> Hi Xunlei,
> On 06/30/17 at 11:18am, Xunlei Pang wrote:
>> We need to know all the kdump targets(not only dump target),
>> this is useful for us to do some extra work related to the
>> type of different targets.
> It is not clear what is "all the kdump targets", can you add more
> words in patchlog?
>
> Looks like it includes dump target and dump_to_rootfs from the code.
> It is better to add the purpose as well why we need this..
Will improve
>
>> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com>
>> ---
>> kdumpctl | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 56 insertions(+)
>>
>> diff --git a/kdumpctl b/kdumpctl
>> index 0e53793..221b461 100755
>> --- a/kdumpctl
>> +++ b/kdumpctl
>> @@ -452,6 +452,60 @@ setup_initrd()
>> fi
>> }
>>
>> +collect_kdump_target()
>> +{
>> + local _dev=$1
>> +
>> + if [ -b "$_dev" ]; then
>> + _dev=$(get_persistent_dev $_dev)
>> + fi
>> +
>> + # Use export to let mkdumprd(etc) also know it.
>> + if [ -n "$KDUMP_TARGETS" ]; then
>> + export KDUMP_TARGETS="$KDUMP_TARGETS $_dev"
>> + else
>> + export KDUMP_TARGETS="$_dev"
> Assume this is for export shared variable for mkdumprd.
>
> Originally in the initial phase of Fedora kexec-tools I wanted to drop
> mkdumprd, use kdumpctl only, but for safe we keep it maybe someone use
> mkdumprd seperately, one can use mkdumprd to generate kdump initrd
> without kdumpctl. If we pass extra things via KDUMP_TARGETS then it
> seems changes the behavior.
This is indeed a small issue.
>
> BTW, in mkdumprd we already have for_each_block_target which can be used for
> this purpose without extra functions?
It's a bit different, we also want to know ssh/nfs target which is non-block.
To solve these issues, I think we can introduce a helper in kdump-lib.sh
like get_kdump_targets(), and call it separately instead of exporting it
as a shared variable, we also can refactor for_each_block_target() using
this new get_kdump_targets().
Yes, I have same thought to call it separately instead of sharing things
between different scripts.
About the networking targets, since they can be easily detected so they
should be not a big problem to handle separately if we have to do
something like omit some network modules etc. If so maybe only the block
target in a general function helper.
Besides, we need a neat way to judge if it is fadump.
Regards,
Xunlei
>
>> + fi
>> +}
>> +
>> +# Collect targets(not only dump target) that will be recognized under kdump.
>> +collect_kdump_targets()
>> +{
>> + local _target _root
>> +
>> + # Do not care about fadump
>> + if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
>> + return
>> + fi
>> +
>> + _target=$(get_block_dump_target)
>> + if [ -n "$_target" ]; then
>> + collect_kdump_target $_target
>> + elif is_ssh_dump_target; then
>> + collect_kdump_target "ssh"
>> + else
>> + collect_kdump_target "nfs"
>> + fi
>> +
>> + # Add the root device if dump_to_rootfs is specified.
>> + ! is_dump_to_rootfs && return
>> + _root=$(get_root_fs_device)
>> + [[ "$_root" = "$_target" ]] && return
>> + if [[ -b "$_root" ]]; then
>> + collect_kdump_target $_root
>> + else
>> + collect_kdump_target "nfs"
>> + fi
>> +
>> + # NOTE:
>> + # dracut parses devices from "/etc/fstab" with the
"x-initrd.mount" option,
>> + # which will be added as host_devs, it also includes usually simple devices
>> + # (say mounted to /boot, /boot/efi/, etc) plus the root device. Then kdump
>> + # must wait for these devices if initramfs is built with
"--hostonly-cmdline".
>> + #
>> + # We don't pass "--hostonly-cmdline" to dracut, so there's
no problem.
>> +}
>> +
>> check_files_modified()
>> {
>> local modified_files=""
>> @@ -693,6 +747,8 @@ check_rebuild()
>> return 1
>> fi
>>
>> + collect_kdump_targets
>> +
>> # Will not rebuild kdump initrd
>> if [ "$force_no_rebuild" == "1" ]; then
>> return 0
>> --
>> 1.8.3.1
>> _______________________________________________
>> kexec mailing list -- kexec(a)lists.fedoraproject.org
>> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
> Thanks
> Dave
_______________________________________________
kexec mailing list -- kexec(a)lists.fedoraproject.org
To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
Thanks
Dave