On Wed, 2011-11-23 at 19:46 +0900, Kazuyoshi Aizawa wrote: > It is guaranteed that getmsg would return single message from > kernel side buffer, aka stream head, and we can expect single > message contain single packet data as tun driver treats packet > as single message. By using getmsg, we don't need to care > about the boundary of the packet data. Hm, looking at the read(2) manual page?, shouldn't we be able to put the tun_fd into 'message-discard' mode, which would make it behave like the tun device does on other operating systems? I might have suggested that if I'd realised it yesterday, but now I'm inclined to stick with the version of your patch that I committed earlier. It's actually slightly more efficient using getmsg() because of the MOREDATA flag. With read() we have to keep reading from the tun_fd until we get EAGAIN, but with getmsg() we can avoid that final unnecessary system call, because we *know* there's nothing left when the MOREDATA bit isn't set. Unless there's some other reason why getmsg() itself is slower than read(), perhaps? -- dwmw2 ? http://pubs.opengroup.org/onlinepubs/007904975/functions/read.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5818 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20111123/89760d05/attachment.bin>
