----- Original Message ----- > Hello Dave, > > Here is the brief background for the patch. > > We had a problem - there was a page which contained some structure which we > weren't able to identify, > but we could specify approximate size of this structure. Also it might be > said that this structure contains > two adjacent lists. But it was really difficult to tell which exactly > structure it is. > > So, here is a patch for such kind of functionality - you can list data > structures which size is in some range and > which contain fields of some particular type. Alexandr, The key point above is: "We had a problem" Since 1999, there have been exactly 2 new commands added, "ipcs" and "tree", which address a major kernel subsystem, and support for dumping radix or red-black tree contents. It is very tempting to create a new crash command to address a very specific issue. And while I appreciate the work you've put into this effort, there's no way I'm going to add something this bug-specific to the general command set. That being said, this patch is a prime candidate for a crash extension module, which I am always willing to add new extension modules to the upstream extensions page. Now, there is a complication in that you've modified/added a signficant chunk of gdb-specific code, which is typically not done for extension modules. However I have done it a couple times in the past, but only if the gdb code changes do not affect the normal crash utility interaction with gdb. For example, I'm not entirely clear on your change to recursively_search_psymtabs() -- I'm presuming that the "name_matcher" argument would *always* be set to a function when the function is called by existing gdb code? If that's true, then I would be willing to make the gdb changes for your extension module. Another alternative would be to make it an option to an existing command, Perhaps the "whatis" command could be expanded? Thanks, Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility