Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
- From: David Howells <dhowells@xxxxxxxxxx>
- Date: Wed, 21 Mar 2007 18:10:35 +0000
David Howells <dhowells@xxxxxxxxxx> 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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
- From: David Howells
- Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
- From: Alan Cox
- [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
- From: David Howells
- Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
- Prev by Date: Re: [PATCH] sched: rsdl improvements
- Next by Date: the lighter side of janitorial work
- Previous by thread: Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
- Next by thread: Re: [mit-devel] Re: module-init-tools-3.3-pre10 available
- Index(es):
Relevant Pages
|
