zfcp_diag_u..._data_buffer(9)

📦 version 7.3.1, in nixpkgs unstable

💅 zfcp_diag_u..._data_buffer(9) — Kernel API Manual, section 9, bestie 🎀

ok so welcome to the kernel API manual, page zfcp_diag_u..._data_buffer(9) — yes the name is literally truncated with dots, that's not me being lazy, that's the actual page name, iykyk ✨

🌸 NAME 🌸

zfcp_diag_update_port_data_buffer — the implementation of &typedef zfcp_diag_update_buffer_func whose whole entire job is to collect and update Port Data. that's it. that's the gig. 💖

✨ SYNOPSIS ✨

int zfcp_diag_update_port_data_buffer (struct zfcp_adapter *const
       adapter );

🦋 ARGUMENTS 🦋

  • adapter — the Adapter we're collecting Port Data from. that's the one. give it to me. 🫶

🔥 DESCRIPTION 🔥

okay so bestie, listen up, because this is the important part:

this call is SYNCHRONOUS ! 🚨

like, capital letters, exclamation mark, the whole thing. it blocks until the respective command has finished completely, or has failed in some way. no sneaky background vibes, no "i'll get back to you later" — it sits there and waits. main character energy but make it a blocking syscall 💀

⭐ RETURN ⭐

  • 0 — Successfully retrieved new Diagnostics and Updated the buffer 🎉 and ooh, plot twist: this also covers the cases where data was retrieved but it was incomplete. so no, 0 doesn't automatically mean everything's perfect, you'll have to check the flag `incomplete` of struct zfcp_diag_header yourself. vibe check your struct, bestie 🙈
  • see zfcp_fsf_exchange_port_data_sync for possible error-codes (and note: excluding -EAGAIN). so go look over there for the full error menu, just know -EAGAIN is not on it 💅

🧚 SEE ALSO 🧚

Kernel file ./drivers/s390/scsi/zfcp_diag.c — go read it, it's giving lore:

and that's the whole page, no cap 🫶 this little number lives in ./drivers/s390/scsi, dated October 2026 — so go forth, collect that Port Data, and slay ✨👑💜

📦 where this page comes from