[PATCH makedumpfile 0/9] Improvements to makedumpfile extensions, plus userspace stack tracing extension

[HAGIO KAZUHITO(萩尾 一仁)]

Hi Tao,

On 2026/08/11 15:11, Tao Liu wrote:

>>>>> and Tao, please check if your extension can be rebased on this
>>>>> patchset.  and also if you agree the extension list, please provide
>>>>> the information.
> 
> I have checked my extension to rebase on this patchset. The result is:
> 
> 1) Rebase fails, but only due to conflicts within extensions/Makefile.
> These are small issues which would be very easy to fix.
> 2) Once 1 is fixed, after compile, my extension can work as expected.
> However this is a coincidence.  Because my extension takes callback
> as:
> 
> int extension_callback(unsigned long pfn, const void *pcache)
> {
>          struct ft_page_info *cur = NULL;
>          return filter_page(pfn, &cur);
> }
> 
> But this patchset changed the callback into:
> run_extension_callback(unsigned long pfn, const void *pcache, const
> struct pginfo *i)
> 
> My extension works because it only takes pfn as parameter, and the
> handle_cbs[i]->cb() doesn't check function parameters. However, I
> don't think it is a major issue, once the modification on extension.c
> merged upstream, I can adjust the function signature of mine
> accordingly.

Thank you for checking.  My main concern was the change in behavior, 
particularly with compound pages.  If your extension works well after 
some adjustments, that's good to hear.  I will merge the patch set later.

> 
>>>>
>>>> Sure, I will check for the rebase. In the meantime, will the
>>>> extensions to be maintained in one repo (e.g. makedumpfile extensions
>>>> repo, so everyone can PR to it), or they are maintained in each of
>>>> individual repos, and link them under
>>>> https://github.com/makedumpfile/makedumpfile/wiki#extensions?
>>>
>>> I am open to either. I would be willing to co-maintain an extensions
>>> repository with Tao, for example at github.com/makedumpfile/extensions,
>>> so that there is a common place to contribute. That is, if this
>>> arrangement would work for all?
>>>
>>> If we did create a common repository, I think we'd want to set up some
>>> expectations on the quality & maintenance. EG, some may be marked as
>>> "maintained" with a maintainer and a scope of maintenance (supported
>>> kernel versions, supported architectures, etc), and others as
>>> "unmaintained", where we just make sure that they build & run with
>>> makedumpfile, but don't validate their behavior on specific kernels or
>>> architectures.
>>>
>>> On the other hand, if it's preferable to stay separate, then I'm happy
>>> to find another place to maintain the userstack & elfheader extensions.
>>
>> I was thinking of separate repositories.  A single repository would be
>> fine, but for now I have no plans to create one within the makedumpfile
>> organization.
>>
>> (Looking back at crash extensions, some become obsolete quickly or
>> have very specific functionality, making it difficult for anyone
>> other than the original author to maintain.  For this reason, I think
>> it is best for the authors themselves to manage them.)
> 
> Understood, extensions are designed to address one specific issue, and
> is easy to get outdated when makedumpfile/crash utility keeping
> following up the latest kernel, but extensions are often left behind
> due to low usage. Let's go with maintainling the extensions by each
> authors seperately and link them into
> https://github.com/makedumpfile/makedumpfile/wiki#extensions

Thank you for your understanding.  for now, please let me know the 
information of your extension once it's ready.

Thanks,
Kazu