Page MenuHomeFreeBSD

[2/2] mps(4): remove SATA ID command cancellation hack
ClosedPublic

Authored by cem on Dec 20 2018, 12:32 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Dec 4, 5:50 PM
Unknown Object (File)
Oct 14 2024, 1:51 PM
Unknown Object (File)
Sep 20 2024, 7:34 AM
Unknown Object (File)
Sep 19 2024, 7:11 AM
Unknown Object (File)
Sep 12 2024, 12:09 AM
Unknown Object (File)
Sep 8 2024, 12:44 PM
Unknown Object (File)
Sep 7 2024, 6:49 PM
Unknown Object (File)
Sep 7 2024, 10:04 AM
Subscribers

Details

Summary

Add a generic mechanism to override mps_wait_command's timeout behavior,
which continues to invoke reinit by default. Invokers who set
cm_timeout_handler may avoid automatic reinit and do their own handling.

Adapt mpssas_get_sata_identify to this mechanism and remove its callout
hack.

Test Plan

It compiles, but I have not tested it further in any way.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sys/dev/mps/mps.c
3090 ↗(On Diff #52183)

Unrelated to this change, is this valid if !mtx_owned(sc->mps_mtx)? Line 3077 above suggests it may not be owned. If it is expected to be owned, maybe mtx_assert() is appropriate?

One small thing to consider is whether to create a new typedef for cm_timeout_handler, even if it's the same implementation is mps_command_callback_t for now. The reason is that we might want to evolve this into a different function call signature for the timeout handler. This might be useful for mps_scsiio_timeout().

Also, can you add the same changes for mpr?

One small thing to consider is whether to create a new typedef for cm_timeout_handler, even if it's the same implementation is mps_command_callback_t for now. The reason is that we might want to evolve this into a different function call signature for the timeout handler. This might be useful for mps_scsiio_timeout().

I figure we can just make the new definition if needed, if/when we cross that bridge. So I have a weak preference for just keeping it as-is. If you have a strong preference to do it now instead, I'm happy to change it.

Also, can you add the same changes for mpr?

Yeah, no problem. To avoid duplicating the same iterative changes during review, though, I'd prefer to wait until we get to a point where we're happy with the mps changes alone first, then copy them to mpr and confirm the mpr changes look ok as well. Is that ok, or would you prefer having both sets of changes sooner? I'm ok doing that, it's just more work for me.

Thanks for taking a look.

This revision is now accepted and ready to land.Dec 20 2018, 5:03 AM
This revision now requires review to proceed.Dec 21 2018, 12:30 AM
This revision is now accepted and ready to land.Dec 21 2018, 8:24 PM
This revision was automatically updated to reflect the committed changes.