Page MenuHomeFreeBSD

virtio_blk: Populate d_attachment
AcceptedPublic

Authored by jrtc27 on Aug 28 2024, 11:11 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Oct 5, 3:49 PM
Unknown Object (File)
Wed, Oct 2, 5:42 AM
Unknown Object (File)
Mon, Sep 30, 11:28 PM
Unknown Object (File)
Sep 8 2024, 2:43 PM
Unknown Object (File)
Aug 30 2024, 5:47 PM
Subscribers
None

Details

Reviewers
imp
mav
Summary

It's not hard to go from vtbdN to vtblkN, but we should nevertheless be
helpful and provide the underlying newbus device name.

MFC after: 1 month

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 59218
Build 56105: arc lint + arc unit

Event Timeline

jrtc27 created this revision.
This revision is now accepted and ready to land.Aug 29 2024, 1:24 AM

What do you both think of https://reviews.freebsd.org/P646 as a more systematic way of addressing this? All the CAM-based drivers diligently snprintf with their SIM's name and unit, but NVD is the only other driver which fills in d_attachment. I could just copy the strlcpy to every driver that's missing it, but it seems like it might be beneficial to be able to give GEOM the device_t itself for the attachment and let it fill in whatever it wants, currently just d_attachment?

(NB: I'm aware that it changes the behaviour for nvd with QUIRK_AHCI, which I'd argue might be a feature, especially since nda looks like it'll use the SIM's name, which is the nvmeX rather than the ahciY, but can of course be addressed should the current attachment reporting be desired)

What do you both think of https://reviews.freebsd.org/P646 as a more systematic way of addressing this?

Would we have any more use for the passed device (thinking about d_hba_*, etc), it would make more sense. Otherwise I don't have strong preferences.