Refactored mkdumprd and mkfadumprd into functions with relation to issue #140

[ajahagir-rh]

Moves mkdumprd and mkfadumprd functionality into kdumpctl as internal functions. This eliminates duplicate kdump.conf parsing.

Resolves #140

Changes

• kdumpctl: Added 11 top-level helper functions (avoiding nested function anti-pattern)
• kdumpctl: Added `_mkdumprd()` and `_mkfadumprd()` internal functions that reuse the already-parsed OPT array
• kdumpctl: Updated `rebuild_kdump_initrd()` and `rebuild_fadump_initrd()` to call internal functions
• kdumpctl: Added hidden CLI commands `_mkdumprd` and `_mkfadumprd` for backward compatibility
• mkdumprd & mkfadumprd: Converted to thin wrapper scripts with deprecation warnings
• mkdumprd.8: Added deprecation documentation

[gemini-code-assist]

Code Review

This pull request deprecates the standalone mkdumprd and mkfadumprd scripts, refactoring their core logic into internal functions within kdumpctl to eliminate duplicate configuration parsing and improve efficiency. The original scripts are converted into thin compatibility wrappers, and the man page is updated accordingly. The code review identified several critical shell scripting issues in the refactored code, including a pipeline masking issue in _get_fs_size, a silenced exit status in add_mount, incorrect --debug flag forwarding in the wrappers, potential integer comparison errors in _check_size, and risky eval usage in _check_user_configured_target.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[prudo1]

Hi @ajahagir-rh,

thanks for submitting the PR. I'm not fully done reviewing the changes in detail. Nevertheless there are a few high-level issues I want to discuss.

First of all, please split up the PR in multiple commits with each one only doing 'one change' and write proper commit messages for them. There are multiple reasons for that.

1. Having multiple commits helps reviewers massively as they only need to understand one change at a time.
2. Similar it helps finding bugs introduced by your PR. You always should assume that you introduce new bugs with every change. To find them git bisect is very helpful. It allows you to identify the commit that introduced the bug/new behavior. However, if that commit is massive and contains multiple changes, knowing the commit doesn't help you with identifying the problem.
3. Commit messages are an extremely important, if not even the most important, piece of documentation for developers. They allow us to understand why the code is the way it is. Knowing that is extremely important! It prevents us to make the same mistakes over and over again. That's also why commit messages should focus on describing why a commit is needed not what it does (ideally this should be obvious when you stick to the one-commit-per-change-rule).

You can have a look at #33, If you want same inspiration on how to split up the PR.

While at it, please also add your Signed-off-by: to the commits. With this you show that you are the author of the code and that you have permission to submit it to upstream, e.g. that you didn't copy any code that is protected by a incompatible license. You can automatically add your Signed-off-by: by using the -s option with git commit.

Furthermore, my long term goal for kdump-utils is to make it more modular. To achieve that it is necessary to split up kdumpctl into multiple files. With each of these files handling one aspect of it. In that picture rebuilding the initrd is a prime candidate to be split out as it is pretty much self-contained. That's why I moved the code to a new kdump-lib-dracut.sh rather than including it in kdumpctl on the branch I gave you. I'd appreciate if you could do the same.

Additionally, while I really appreciate that you are thinking about backward compatibility, I don't think it makes sense to keep it in this case. mkdumprd was always intended only to be used via kdumpctl and I cannot think about any reason why a user would want to do it differently. In fact using it directly can lead to horrible consequences, as the issue linked to in #140 shows. So IMHO breaking backward compatibility is not a bug but a feature in this case. Worst thing that can happen is that we have to re-introduce the backward compatibility later again in case some one complains.

Finally, when you fix issues while the PR is in discussion, like the issues reported by Gemini. You only have to add a new commit to the PR, if that problem already existed before. If the problem was introduced by one of your commits it is better to update the commit rather than adding a new one. This helps to keep the git history shorter and easier to traverse.

Thanks
Philipp

[liutgnu]

I have run a local test against it, no issue found and all tests passed. But I haven't look into the code yet. PS. to run a local test:
$ tools/build-rpm.sh 44
$ tmt run --environment KDUMP_UTILS_RPM="/root/kdump-utils/x86_64/kdump-utils-1.0.44-1.fc44.x86_64.rpm" -a
...
total: 23 tests passed

[prudo1]

I have run a local test against it, no issue found and all tests passed. But I haven't look into the code yet. PS. to run a local test: $ tools/build-rpm.sh 44 $ tmt run --environment KDUMP_UTILS_RPM="/root/kdump-utils/x86_64/kdump-utils-1.0.44-1.fc44.x86_64.rpm" -a ... total: 23 tests passed

Hi Tao, thanks for testing!

[prudo1]

Hi Akhilesh,

thanks for the update. All in all it looks much better. But unfortunately I have to nag again. Part of it is on me...

When I said that a commit should only contain 'one change' I didn't meant that it should only contain changes to one file. I rather meant that it should only contain one change in the programs logic, which might require to touch multiple files. For example when you remove/rename a file the commit needs to contain the actual removal/renaming plus all changes related to it, e.g. Makefile, spec file, files that source the other file, etc..

This is because it's important that not only the PR as whole works but every single commit in it. This is required for git bisect I mentioned earlier. With git bisect you perform a binary search on the git log to find a commit that introduced a bug. That requires to install and run the code on multiple commits from the log. If one of them doesn't 'work' (e.g. doesn't compile or install, exits with an error early, etc.). You cannot continue with git bisect but have to manually work around it. Which makes life for the person triaging the bug much harder.

In addition having multiple 'logical changes' in one commit makes reviewing a lot harder. For example in your first commit you basically moved the code from mkdumprd/mkfadumprd into a new file and at the same time made some changes to it, i.e. made use of the OPT array, converted _timeout_cmd to an array. The problem is that the diff from the git commit only shows a big block of lines that have been added. For me as a reviewer this means that I have to go through every line of the final code to find out which line has changed and if it has been changed correctly. If you had one commit that does the move (and no functional change) and one (or more) commit(s) that contain the changes. It would make life for reviewer much easier. Then the diff in the commit(s) that add the change will clearly show which lines have been updated and what has changed. Plus for the commit that moved the code I could focus on all the other changes that come with it, e.g. Makefile, spec file, etc.. In the end this will not only make my life easier but will also contribute to less bugs as they are caught before they even get merged.

BTW, having code that is easy to review is not only important to get code merged. It also helps with investigating bugs. At least in my workflow I use git blame quite a lot when I spot code that looks 'fishy' to me. It shows for every line in the file the last commit that has changed it. This helps me a lot to understand the history of the code and why certain changes have been made in the past. But for that the commits need to be easy to understand. So having a commit that is hard to review doesn't only hurt once but over and over again.

That's why I'm so keen on having not only the code but also the commits in good shape.

Thanks
Philipp

[prudo1]

Here is an example on why moving and changing code should be two separate commits. How did the old code look like? What has changed?
Of course I could look it up by applying this commit and look at mkdumprd. But there it's also only one line in a huge block of code. Plus it makes it hard to spot the other related lines that need to be updated to make this change and check if they have been updated correctly.
For me as a reviewer it would be much easier when such a change is in a separate commit. Then the diff will tell me exactly what has changed.

[prudo1]

Here is an example on what would break git bisect. In case someone would try to run kdumpcrl rebuild after only applying this commit it would fail. Because mkdumprd tries to call this function which is now undefined.
The same problem happens by only updating the Makefile/spec file in the last commit. If someone tries to run make install or build the rpm without applying the last commit it will fail.