Re: [PATCH makedumpfile 0/9] Improvements to makedumpfile extensions, plus userspace stack tracing extension
Tao Liu <[email protected]>
| Newsgroups | org.infradead.lists.kexec |
|---|---|
| Message-ID | <CAO7dBbWSkjn+po1S9MOoyLdVGWoiiJWc2jcsYNtgrM+nzRV93g@mail.gmail.com> |
Hi Kazu & Stephen, Please check my comments on the patchset. For the reset of the patchset, LGTM. Reviewed-by: Tao Liu <[email protected]> On Wed, Aug 12, 2026 at 5:07 PM Tao Liu <[email protected]> wrote: > > Hi Kazu, > > On Wed, Aug 12, 2026 at 1:32 PM HAGIO KAZUHITO(萩尾 一仁) > <[email protected]> wrote: > > > > 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. > > > OK, sounds good! > > > > > > >>>> > > >>>> 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. > > Please check my extension link: > https://github.com/liutgnu/mkdf-extension-amdgpu-mm-filtering > > Thanks, > Tao Liu > > > > Thanks, > > Kazu