Accessing static drive info w/o ATA identify and lockup with camcontrol identify

[Alan Somers]

On Thu, Dec 10, 2015 at 9:25 AM, Ravi Pokala <rpokala at mac.com> wrote:
> -----Original Message-----
>
>
> From: <asomers at gmail.com> on behalf of Alan Somers <asomers at freebsd.org>
> Date: 2015-12-10, Thursday at 08:15
> To: Ravi Pokala <rpokala at panasas.com>
> Cc: Kevin Bowling <kevin.bowling at kev009.com>, Ravi Pokala <rpokala at mac.com>, "freebsd-scsi at freebsd.org" <freebsd-scsi at freebsd.org>
> Subject: Re: Accessing static drive info w/o ATA identify and lockup with camcontrol identify
>
>>On Thu, Dec 10, 2015 at 9:10 AM, Pokala, Ravi <rpokala at panasas.com> wrote:
>>>Interesting. I never noticed that firmware wasn't already included in "struct disk", like drive model and serial number already are. It should be trivial to add, but keeping a copy of the string will of course make "struct disk" larger. That might have implications on KBI compatibility for out-of-tree drivers...? Again, I'm not sure.
>>
>>
>>This information is already perserved in CAM, if not in GEOM.  For
>>SCSI disks, look at (struct cam_device).inq_data.revision.  For ATA
>>disks, look at (struct ccb_getdev).ident_data.revision.
>
> Right, but it sounded like Kevin was looking for a way to get this from userland. That means through something like `geom disk list' (or the raw XML from which that is parsed).
>
> -Ravi
>

Actually, it is possible to get that info in userland, though a little
awkward.  You can do 'cam_open_device("da13")' to get a struct
cam_device.  Getting the ccb_getdev is harder though.  Look at
get_cgd() from camcontrol.c.  Even though it looks like it's sending a
CCB, the CCB actually gets processed by CAM and doesn't result in any
I/O hitting the disk.

-Alan