sd_ddi_scsi_poll can stop saving pkt fields
There is a concern in sd's scsi_ddi_scsi_poll about preserving packet fields (pkt_time, pkt_flags, and pkt_comp).
This is silly, since these fields are only established by sd itself, and consumed only by lower drivers. It has no logic internally that relies on these fields being preserved across calls to this function.
- pkt_time is only set if left unset (should never be the case), and is never consumed except by the HBA
- pkt_flags is pretty much never changed, except to ensure that FLAG_NOINTR set set. HBAs only read it.
- pkt_comp should always be unset for these commands.
A packet that is used for polled I/O (with this command) is never used for anything else.
The callers of this function are:
1. sd_scsi_poll -- it does not consume these fields, and will actually destroy the packet when it's done
2. sd_send_polled_RQS - the only callers to it seem to use this to clear contingent allegiance on the HBA - it uses a global packet for the unit.
Additionally, the comment in sd_ddi_scsi_poll is wrong:
/* * XXX there is nothing in the SCSA spec that states that we should not * do a callback for polled cmds; however, removing this will break sd * and probably other target drivers
In particular, the man page for scsi_pkt(9S) says:
Run command with no command
completion callback. Command
is complete upon return from
And further, tran_start(9e) says:
If the flag FLAG_NOINTR is set in pkt_flags in pkt, tran_start()
should not return until the command has been completed. The command
completion callback pkt_comp in pkt must not be called for commands
with FLAG_NOINTR set, since the return is made directly to the
function invoking scsi_transport(9F).
When the flag FLAG_NOINTR is not set, tran_start() must queue the
command for execution on the hardware and return immediately. The
member pkt_comp in pkt indicates a callback routine to be called upon
No data to display