----- "Bob Montgomery" <bob.montgomery(a)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