David Howells <[EMAIL PROTECTED]> wrote: > > - recvmsg not supporting MSG_TRUNC is rather weird and really ought to be > > fixed one day as its useful to find out the sizeof message pending when > > combined with MSG_PEEK > > Hmmm... I hadn't considered that. I assumed MSG_TRUNC not to be useful as > arbitrarily chopping bits out of the request or reply would seem to be > pointless.
But why do I need to support MSG_TRUNC? I currently have things arranged so that if you do a recvmsg() that doesn't pull everything out of a packet then the next time you do a recvmsg() you'll get the next part of the data in that packet. MSG_EOR is flagged when recvmsg copies across the last byte of data of a particular phase. I might at some point in the future enable recvmsg() to keep pulling packets off the Rx queue and copying them into userspace until the userspace buffer is full or we find that the next packet is not the logical next in sequence. Hmmm... I'm actually overloading MSG_EOR. MSG_EOR is flagged on the last data read, and is also flagged for terminal messages (end or reply data, abort, net error, final ACK, etc). I wonder if I should use MSG_MORE (or its lack) instead to indicate the end of data, and only set MSG_EOR on the terminal message. MSG_MORE is set by the app to flag to sendmsg() that there's more data to come, so it would be consistent to use it for recvmsg() too. David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
