In article <25322.1446399...@andromeda.noi.kre.to>, Robert Elz <k...@munnari.oz.au> wrote: > Date: Sun, 1 Nov 2015 15:41:04 +0000 (UTC) > From: mlel...@serpens.de (Michael van Elst) > Message-ID: <n15bqg$3og$1...@serpens.de> > > | 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