From owner-freebsd-hackers Sun Aug 1 8:50:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (Postfix) with SMTP id 2E97714BF9 for ; Sun, 1 Aug 1999 08:50:54 -0700 (PDT) (envelope-from will@ns.oeno.com) Received: (qmail 1695 invoked by uid 1001); 1 Aug 1999 15:50:44 -0000 Date: 1 Aug 1999 15:50:43 -0000 Message-ID: <19990801155043.1692.qmail@ns.oeno.com> From: Ville-Pertti Keinonen To: wes@softweyr.com Cc: dillon@apollo.backplane.com, hackers@FreeBSD.ORG In-reply-to: <37A399C1.43B5154E@softweyr.com> (message from Wes Peters on Sat, 31 Jul 1999 18:50:09 -0600) Subject: Re: Documenting writev(2) ENOBUFS error Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > :> [ENOBUFS] Insufficient system buffer space exists to complete the op- > > > :> eration. > > > : > > > :Do you know what kind of circumstances that error *really* occurs > > > :under? > > > > So you can get ENOBUFS not related to mbufs for UDP/local datagram > > sockets, but you should never get ENOBUFS from write for TCP sockets > > or local stream sockets. > > So, do you want to enumerate the cases in which this error can occur in the > man page? This is not generally done, now that we have verified it is > possible for the system to generate ENOBUFS on a writev. I think the text > stands as it is. It should probably mention that it doesn't occur for most files (or that it only occurs for datagram sockets - although it probably applies to some types of raw sockets, too, and possibly non-PF_INET/PF_UNIX sockets) to avoid people doing unnecessary checking or implementing kernel code that bails out when it shouldn't. It should be a fair requirement that the kernel continue to never fail with ENOBUFS for a write to a reliable stream (local file, fifo, pipe or stream socket) and that such cases be treated as bugs. I would assume that this corresponds to how other systems operate, as well. Of course I'm no authority on this, and I'm not sure about NFS writes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message