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
Differential D46469
virtio_blk: Populate d_attachment jrtc27 on Aug 28 2024, 11:11 PM. Authored by Tags None Referenced Files
Subscribers None
Details
Diff Detail
Event TimelineComment Actions 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) Comment Actions 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. |