On 9/13/21 12:25 PM, Michael Tuexen wrote:
On 13. Sep 2021, at 18:29, John Baldwin <[email protected]> wrote:
On 9/12/21 1:39 PM, Mark Johnston wrote:
The branch main has been updated by markj:
URL:
https://cgit.FreeBSD.org/src/commit/?id=b864b67a0d197f59ecf6698940600956ceee2cae
commit b864b67a0d197f59ecf6698940600956ceee2cae
Author: Mark Johnston <[email protected]>
AuthorDate: 2021-09-12 20:05:49 +0000
Commit: Mark Johnston <[email protected]>
CommitDate: 2021-09-12 20:39:44 +0000
socket: Do not include control messages in FIONREAD return value
Some system software expects to be able to read at least the number of
bytes returned by FIONREAD. When control messages are counted in this
return value, this assumption is violated. Follow Linux and OpenBSD
here (as well as our own kevent(EVFILT_READ)) and only return the number
of data bytes available.
Reported by: avg
MFC after: 2 weeks
In a somewhat similar vein, it would be nice to eventually have new ioctls
to know how much data and control are available in the next message for
datagram-oriented sockets. Right now if you are working with a datagram
socket with variable-sized messages there's no good way to know how big the
next message is (to resize a read buffer) as FIONREAD can count multiple
messages. There's also no way at all to cope with control messages aside
from retrying with some naive algorithm like doubling the size if MSG_CTRUNC
is set, but that also requires always using MSG_PEEK so that you always
end up reading a message at least twice.
That still requires two system calls. In SCTP, there is a CMSG you can
receive with a messages, which contains the metadata of the next message
you will receive.
So it might be an idea to define a CMSG containing the length of the next
message (if available).
We could at least just have a single ioctl that returns a struct with
two members (data length and control length) perhaps to get it back down
to just 1 syscall similar to FIONREAD.
--
John Baldwin
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "[email protected]"