STRUCT NVME_FC_REMOTE_PORT(9)
π struct nvme_fc_remote_port(9)
okay so this is a page from the Kernel API Manual (yes, the kernel has its own manual, we stay educated π), and it's all about struct nvme_fc_remote_port β the little data structure that gets passed between the NVME-FC transport and a LLDD so they can both point at a remote NVME subsystem port. It's allocated/created by the nvme_fc_register_remoteport() transport interface. That's the whole vibe. π¦
β¨ SYNOPSIS β¨
struct nvme_fc_remote_port {
u32 port_num;
u32 port_role;
u64 node_name;
u64 port_name;
struct nvme_fc_local_port *localport;
void *private;
u32 dev_loss_tmo;
u32 port_id;
enum nvme_fc_obj_state port_state;
};
π Members π
okay bestie let's go field by field, no skips, we're thorough here π
port_numβ the NVME-FC transport remote subsystem port number. it's giving "which port" energy.port_roleβ the NVME roles that are supported on the port (peepFC_PORT_ROLE_xxxfor the actual options, iykyk).node_nameβ the FC WWNN for the port. iconic identifier, fr fr.port_nameβ the FC WWPN for the port. yes it's a different name thannode_name, they're different things, don't mix them up πlocalportβ pointer to the NVME-FC local host port that the subsystem is connected to.privateβ pointer to memory allocated alongside the remote port structure, and this chunk is specifically for the LLDD to use. the length of that buffer corresponds to theremote_priv_szvalue that the LLDD supplies in thenvme_fc_port_template. π«Άport_idβ the FC N_Port_ID currently assigned to the port. the upper 8 bits must be set to 0 β that part is a hard requirement, not a suggestion, so please actually do it πport_stateβ the operational state of the remote port. valid values areONLINEorUNKNOWN. that's the whole vibe check. β
πΈ Description πΈ
so there's two flavours of fields living in here:
Fields with static values for the port. these get initialized by the port_info struct that gets supplied to the registration call.
Fields with dynamic values. these ones can change based on link state or login state, and the LLDD may reference the fields directly to change them. they're also initialized by the port_info struct supplied to the registration call. so like, same origin story, different energy going forward. π«
π₯ SEE ALSO π₯
go read these next, bestie, they're all in the kernel file ./include/linux/nvme-fc-driver.h:
struct nvmefc_ls_req(9)struct nvmefc_ls_rsp(9)struct nvme_fc_port_info(9)struct nvmefc_fcp_req(9)struct nvme_fc_local_port(9)struct nvme_fc_port_template(9)struct nvmet_fc_port_info(9)struct nvmefc_tgt_fcp_req(9)struct nvmet_fc_target_port(9)struct nvmet_fc_target_template(9)
ngl the whole family of these structs lives under ./include/linux, so if you're lost, that's your first stop π§
and that's the page, periodt π this cutie lives in ./include/linux, and the version we're stanning is dated October 2026 β mwah, go forth and register those remote ports responsibly πβ¨
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms