hvc_iucv_write(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸŽ€ NAME πŸŽ€

hey bestie πŸ’– welcome to the Kernel API Manual page for hvc_iucv_write(9). The short version is literally this: hvc_iucv_write β€” Receive IUCV message & write data to HVC buffer.

✨ SYNOPSIS ✨

okay so here's the signature, and yes we are keeping every space and the ssize_t return type exactly as it was:

ssize_t hvc_iucv_write (struct hvc_iucv_private *priv , u8 *buf , size_t
count , int *has_more_data );

πŸ’… ARGUMENTS πŸ’…

  • priv β€” Pointer to struct hvc_iucv_private. That's the private struct, your main character for this function.
  • buf β€” HVC buffer for writing received terminal data.
  • count β€” HVC buffer size.
  • has_more_data β€” Pointer to an int variable.

πŸ¦‹ DESCRIPTION πŸ¦‹

So here's the tea β˜•: hvc_iucv_write picks up pending messages from the input queue and receives the message data, then writes that data to the buffer you passed as buf.

If the buffer size count is less than the data message size, the message is kept on the input queue, and has_more_data is set to 1. If all message data has been written, the message is removed from the input queue. periodt πŸ’…

The function returns the number of bytes written to the terminal. It returns zero if there are no pending data messages available or if there is no established IUCV path. If the IUCV path has been severed, then -EPIPE is returned to cause a hang up β€” and that hang up is issued by the HVC layer.

🚨 okay but like, pay attention to this bit: -EPIPE is the return value that causes a hang up, and the HVC layer is the one issuing that hang up. No cap, that's the documented flow.

🌈 SEE ALSO 🌈

Kernel file: ./drivers/tty/hvc/hvc_iucv.c β€” and here's the whole squad, all of them, exactly as listed:


that's a wrap, bestie πŸŽ€πŸ’– this page's source/version footer is ./drivers/tty/hvc, the date is October 2026, and the footer name is hvc_iucv_write(9). slay ✨

πŸ“¦ where this page comes from