----- "Michael Holzheu" <holzheu@xxxxxxxxxxxxxxxxxx> 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? Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
