Re: [Crash-utility] dev command deteriorates with new kernels

----- "Bob Montgomery" <bob.montgomery(a)hp.com&gt; wrote: > On Fri, 2009-06-05 at 14:53 +0000, Dave Anderson wrote: > > > > > I've attached what I'm going with. I've added the capability of getting > > the file_operations from the cdev_map when necessary. The block device > > code was also suffering from bit-rot as well, and so I put in a new > > collector function that uses the bdev_map as well. > > Dave, this looks good. Two issues: > > 1) Add "-f" to dev help? (What does it mean to still be a "(none)" device?) It means that a pointer to a file_operations either doesn't exist (or that I have no clue how to find it...) For the hell of it I added that -f flag to show those devices in case somebody's interested. > > 2) The old code found the block extended device number (a feature added > to the kernel by a 25 Aug 2008 patch from Tejun Heo): > > 259 blkext (unknown) > > Also shown in /proc/devices: > ... > Block devices: > 1 ramdisk > 259 blkext > 7 loop > 11 sr > 104 cciss0 > > Deliberate omission? I did see that, and I forget now how the old code found it (although the function still exists), but the structures being used now are bdev_map.probes[] and major_names[]: crash> whatis struct kobj_map struct kobj_map { struct probe *probes[255]; struct mutex *lock; } SIZE: 2048 crash> whatis major_names struct blk_major_name *major_names[255]; crash> where the kernel's kobj_map.probes[] array size is just hardwired to 255, and the major_names[] array size is BLKDEV_MAJOR_HASH_SIZE which is 255. So obviously 259 won't be found.

If you want to figure out how to show it, send me a patch. At this point I'm about ready to deprecate the whole command... ;-) Dave > > Thanks for cleaning this up, > Bob Montgomery