sci_remote_device_destruct(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ NAME ✨

okay so bestie, welcome to the sci_remote_device_destruct(9) page from the Kernel API Manual πŸ’…. This one is all about free remote node context and destruct β€” like, the remote device gets its little goodbye moment.


πŸŽ€ SYNOPSIS πŸŽ€

enum sci_status sci_remote_device_destruct (struct isci_remote_device
       *idev );

🫢 ARGUMENTS 🫢

  • idev β€” this parameter specifies the remote device to be destructed. that's the one we're saying bye to, no cap.

πŸ”₯ DESCRIPTION πŸ”₯

Remote device objects are a limited resource. As such, they must be protected. Because of that, calls to construct and destruct are mutually exclusive and non-reentrant β€” so no chaotic parallel grabbing, bestie. periodt.

The return value shall indicate if the device was successfully destructed or if some failure occurred. The return-value situation is giving:

  • enum sci_status β€” this value is returned if the device is successfully destructed. (the original page says enum sci_status right there, so we're keeping it exactly, iykyk)
  • SCI_FAILURE_INVALID_REMOTE_DEVICE β€” this value is returned if the supplied device isn't valid (e.g. it's already been destoryed, the handle isn't valid, etc.). yes, "destoryed" is the original spelling β€” the vibe is "already destroyed," but the letters are staying exactly as they are 😭
Lowkey important: construct and destruct are mutually exclusive and non-reentrant, so don't try to do the most and call them all willy-nilly. that's the whole warning, bestie.

🌈 SEE ALSO 🌈


πŸ’– that's the whole page, bestie β€” source/version: ./drivers/scsi/isci, date: October 2026. may your remote devices destruct cleanly and your handles stay valid. stay slay πŸŽ€

πŸ“¦ where this page comes from