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

[Stephen Brennan <stephen.s.brennan@oracle.com>]

HAGIO KAZUHITO(萩尾　一仁)	<k-hagio-ab@nec.com> writes:
> 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.

Hi Kazu, Tao,

I am working on creating a Github repository for this within the Oracle
Github organization for our extensions. This tends to take a while for
approvals. May I share the extension URL when it is available? In the
meantime, you could use the URL of this patch series (or the v2), which
I'll send once we resolve the discussion on Patch 4.

Thanks,
Stephen