[Crash-utility] mod -S and debuginfo kernel rpm

[Guy Streeter]

Dave Anderson wrote:
> ----- "Michael Holzheu" <holzheu at linux.vnet.ibm.com> wrote:
> 
>>> So there would be that restriction as to the *relative* locations of
>>> the .ko and .ko.debug files.  But I don't think that's really all that
>>> burdensome.  
>>>
>>> Comments?
>> I think that's a good proposal!
>>
>> Michael
> 
> OK, so here's the proposal:
> 
> - Make the currently-existing "mod -S <release-dir>" command find both the
>   stripped "<module>.ko" and its associated "<module.ko.debug>"
> 
> Prerequisite:
> 
> - Both the "<module>.ko" and "<module.ko.debug>" files must be located in
>   or under the <release-dir>.
> 
> The search mechanism for the stripped "<module>.ko" file would be:
> 
> - Search the complete <release-dir> tree for "<module>.ko".
> . When found, save the relative directory pathname containing the file,
>   where the <relative-dir-path> would be rooted from <release-dir>. 
> 
> The search mechanism for the associated "<module>.ko.debug" file would be
> done in this order: 
> 
>   1. Search the <release-dir>/<relative-dir-path> directory
>   2. Search the <release-dir>/<relative-dir-path>/.debug directory
>   3. Search the <release-dir>/usr/lib/debug/<relative-dir-path> directory
> 
> This scheme would allow an alternate module/module-debuginfo setup to
> be done like so:
> 
>   $ mkdir <release-dir>
>   $ cd <release-dir>
>   $ rpm2cpio kernel-<release>.rpm | cpio -idv
>   $ rpm2cpio kernel-debuginfo-<release>.rpm | cpio -idv
> 
> And then the modules and their debuginfo data could be loaded using
> the current alternative mechanism:
> 
>   crash> mod -S <release-dir>
> 
> Also, because of the 1-2-3 debuginfo search order above, this would allow
> the copying of "<module>.ko" and "<module>.ko.debug" files into the same
> directory anywhere underneath <target-dir>, or in the ".debug" subdirectory
> of the directory containing "<module>.ko".
> 
> That being the case, it would be easy to handle per-release oddities such
> as the RHEL /lib/modules/<release>/updates directory, by simply copying the
> associated <module>.ko.debug file into the same directory as its stripped file. 
> 
> Guy -- are you on board with this?

This looks good to me.
 In our automated setup environment we always create a script in the
same dir as the vmcore that will start crash with the right vmcore and
vmlinux filenames on the commandline. It would be really cool if we
could specify the module search prefix there as well, so "mod -S" would
"just work". Being able to use "mod -S ." is enough, though.

--Guy