Page MenuHomeFreeBSD

Show HBA path in 'diskinfo -v'.
ClosedPublic

Authored by trasz on Tue, Nov 5, 8:18 PM.

Details

Summary

Add GEOM attribute to report physical device name, and report it
via 'diskinfo -v'. This avoids the need to track it down via CAM,
and should also work for disks that don't use CAM. And since it's
inherited over GEOM hierarchy, in most cases one doesn't need
to walk the GEOM graph either, eg you can use it on a partition
instead of disk itself.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

trasz created this revision.Tue, Nov 5, 8:18 PM
chuck added a subscriber: chuck.Wed, Nov 6, 6:42 PM

Overall, the changes look good to me, but I am having a twinge over "HBA". HBA completely makes sense for SCSI but doesn't at all for NVMe. SATA falls in the middle depending on whether this is a proprietary thing or AHCI.

trasz added a comment.Thu, Nov 7, 1:42 PM

Overall, the changes look good to me, but I am having a twinge over "HBA". HBA completely makes sense for SCSI but doesn't at all for NVMe. SATA falls in the middle depending on whether this is a proprietary thing or AHCI.

I have the same problem - the most factually correct way would be "newbus parent node", but that would be completely unparseable to most of the users.

Any thoughts on merging those two attributes into a single string? I've mimicked the fields from struct ccb_pathinq, but I'm not sure if that's the right thing to do.

chuck added a comment.Thu, Nov 7, 2:27 PM

I have the same problem - the most factually correct way would be "newbus parent node", but that would be completely unparseable to most of the users.
Any thoughts on merging those two attributes into a single string? I've mimicked the fields from struct ccb_pathinq, but I'm not sure if that's the right thing to do.

I'm struggling with this as well. How does "Controller" or perhaps "Drive controller" strike you? With the end result being something like "Controller device name" or "Controller device path". Open to suggestions.

imp added a comment.Thu, Nov 7, 3:33 PM

I have the same problem - the most factually correct way would be "newbus parent node", but that would be completely unparseable to most of the users.
Any thoughts on merging those two attributes into a single string? I've mimicked the fields from struct ccb_pathinq, but I'm not sure if that's the right thing to do.

I'm struggling with this as well. How does "Controller" or perhaps "Drive controller" strike you? With the end result being something like "Controller device name" or "Controller device path". Open to suggestions.

"Attachment:" is closest to what this does. Still, this is of dubious value, so I didn't sweat the name too much given that we'll likely remove it when CAM becomes new-busified.

allanjude accepted this revision.Thu, Nov 7, 5:04 PM

Attachment does seem to fit the bill best

Reviewed by: allanjude

This revision is now accepted and ready to land.Thu, Nov 7, 5:04 PM
trasz added a comment.Thu, Nov 7, 7:00 PM

"Attachment" sounds perfect, thanks!

As of the value - even after newbusification, this should still be useful if inherited, eg over GPART or GELI.

trasz updated this revision to Diff 64077.Fri, Nov 8, 4:05 PM

Rename to "attachment", merge into a single GEOM attribute.

This revision now requires review to proceed.Fri, Nov 8, 4:05 PM
trasz edited the summary of this revision. (Show Details)Fri, Nov 8, 4:07 PM
allanjude accepted this revision.Fri, Nov 8, 7:38 PM

Maybe give Warner a chance to provide any more feedback before we commit this.

This revision is now accepted and ready to land.Fri, Nov 8, 7:38 PM
imp accepted this revision.Fri, Nov 8, 7:49 PM

Maybe give Warner a chance to provide any more feedback before we commit this.

I'm cool with this as is. It fills a need, but one that I hope will have a short-term time horizon.

This revision was automatically updated to reflect the committed changes.