Page MenuHomeFreeBSD

Show HBA path in 'diskinfo -v'.
ClosedPublic

Authored by trasz on Nov 5 2019, 8:18 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 20 2024, 11:16 PM
Unknown Object (File)
Feb 12 2024, 6:40 AM
Unknown Object (File)
Feb 12 2024, 6:40 AM
Unknown Object (File)
Feb 12 2024, 6:40 AM
Unknown Object (File)
Feb 12 2024, 6:40 AM
Unknown Object (File)
Feb 11 2024, 8:55 PM
Unknown Object (File)
Nov 29 2023, 9:12 PM
Unknown Object (File)
Nov 29 2023, 9:12 PM
Subscribers

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 - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 27398
Build 25645: arc lint + arc unit

Event Timeline

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.

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.

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.

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.

Attachment does seem to fit the bill best

Reviewed by: allanjude

This revision is now accepted and ready to land.Nov 7 2019, 5:04 PM

"Attachment" sounds perfect, thanks!

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

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

This revision now requires review to proceed.Nov 8 2019, 4:05 PM

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

This revision is now accepted and ready to land.Nov 8 2019, 7:38 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.