[Crash-utility] dev command deteriorates with new kernels

[Dave Anderson]

----- "Bob Montgomery" <bob.montgomery at hp.com> 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