fc_seq_lookup_recip(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… fc_seq_lookup_recip β€” a vibe check on the Kernel API Manual ✨

Okay so bestie, we're in the <pink>Kernel API Manual</pink> today and the main character is literally fc_seq_lookup_recip. Periodt. Let's get into it πŸŽ€


🌸 NAME 🌸

fc_seq_lookup_recip β€” find a sequence where the other end originated the sequence 🫢

Like, you're not the one who started it, they did, and now you gotta go find that sequence. No cap.


✨ SYNOPSIS ✨

enum fc_pf_rjt_reason fc_seq_lookup_recip (struct fc_lport *lport ,
struct fc_exch_mgr *mp , struct fc_frame *fp );

Look at her. Iconic signature. Ate. πŸ‘‘


πŸ’– ARGUMENTS πŸ’–

  • lport β€” the local port that the frame was sent to 🏠 like, this is the address it landed at bestie
  • mp β€” the Exchange Manager you're looking the exchange up from πŸ” that's the whole point, we're doing a lookup here
  • fp β€” the frame that's attached to the sequence we're hunting for πŸ¦‹ the actual thing we're trying to match up

πŸ¦‹ DESCRIPTION πŸ¦‹

So here's the tea β˜• β€” if fc_pf_rjt_reason comes back as FC_RJT_NONE, then this function will have a hold on the ep, and it's lowkey on the caller to release it. 🫢

Like, not me handing you the ep and expecting you to clean up after yourself, but yes, exactly that. The hold is yours now. Release it. Please and thank you πŸ’…βœ¨

Fr fr, don't forget the release β€” it's giving "leave it on read" energy and nobody wants that 😭

🌈 SEE ALSO 🌈

Kernel file ./drivers/scsi/libfc/fc_exch.c plus the whole extended universe of friends, in the order they appear, because we don't skip anyone in this house πŸ’œ:


That's the whole squad, no gatekeeping πŸ’«

Okay that's the page!! Signing off from ./drivers/scsi/libfc, dated October 2026, and the name on the door is fc_seq_lookup_recip(9) πŸŽ€βœ¨ bye bestie, mwah πŸ’‹

πŸ“¦ where this page comes from