Re: sendmmsg() on NetBSD vs Linux

[christos%astron.com@localhost (Christos Zoulas)]

In article <25322.1446399621%andromeda.noi.kre.to@localhost>,
Robert Elz  <kre%munnari.OZ.AU@localhost> wrote:
>    Date:        Sun, 1 Nov 2015 15:41:04 +0000 (UTC)
>    From:        mlelstv%serpens.de@localhost (Michael van Elst)
>    Message-ID:  <n15bqg$3og$1%serpens.de@localhost>
>
>  | That is a bug in the NetBSD sendmmsg() implementation.
>
>I'm not sure that's necessarily true.   On neither Linux nor NetBSD
>is the msg_hdr field of the struct mmsghdr declared const (the
>mmsghdr itself cannot be, as the msg_len field is intended to be modified).
>
>To me this suggests that user code should not rely upon the sendmmsg()
>call leaving the msg_hdr field untouched (on either linux or NetBSD).
>
>Certainly nothing in the man pages (on either system) suggests that
>doing so is safe.
>
>Relying on undocumented behaviour of the actual linux implementation
>is not wise.
>
>Whether or not NetBSD should be copying back the modified msg_hdr is
>a whole other question - it seems to me, that the sys call would run
>faster if only the msg_len fields were copied back, the msghdr struct
>is 3 pointers, 2 socklen_t's and 2 int's (plus likely alignment padding).
>Maybe doing one big copyout() is better than a bunch of much smaller
>ones, and maybe it depends upon the actual way that the kernel/user
>mem mapping is achieved - it might be better one way on some ports and
>the other on others.

Well, the recvmmsg code did not do it, and it was simple enough to make
both sides do the same :-)... I.e. not scribble to the userland struct
unnecessarily.

christos