From owner-svn-src-head@FreeBSD.ORG Wed Jan 26 17:55:11 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B812106566C; Wed, 26 Jan 2011 17:55:11 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7667A8FC12; Wed, 26 Jan 2011 17:55:11 +0000 (UTC) Received: from lemongrass.sec.cl.cam.ac.uk (lemongrass.sec.cl.cam.ac.uk [128.232.18.47]) by cyrus.watson.org (Postfix) with ESMTPSA id BBD5946B03; Wed, 26 Jan 2011 12:55:10 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Wed, 26 Jan 2011 17:55:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <12EB1BEA-F0AF-4B2A-AFEB-9C38C7994FA8@freebsd.org> References: <201101251739.p0PHdqKX044842@svn.freebsd.org> To: mdf@FreeBSD.org X-Mailer: Apple Mail (2.1082) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r217830 - head/share/man/man9 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 17:55:11 -0000 On 26 Jan 2011, at 17:12, mdf@FreeBSD.org wrote: >> Hmm. Is this description missing mention of how wiring failures are >> handled? (Also, it should probably mention that this call can sleep = for >> potentially quite long periods of time, even if sbuf_printf (and = friends) >> can't). >=20 > I'm not sure how much to write, since some of the wiring failures are > dealt with by the sysctl subsystem and are not documented. >=20 > The current state of the actual code is that a failure in vslock(9) is > ignored, unless it's ENOMEM in which case sysctl_wire_old_buffer sets > the sysctl_req->validlen to 0, which would behave perhaps slightly > unexpectedly for the user since no data will be copied out. >=20 > Any non-ENOMEM failure from vslock() presumably would also have been a > failure from SYSCTL_OUT and this does get squashed, perhaps > incorrectly. >=20 > I'll think about saving the error code so that sbuf_finish can report > it if nothing else has gone wrong. Yeah, no specific opinions on the right answer, except perhaps that = sbuf_new_for_sysctl() failing due to ENOMEM is something worth making it = easy to report to the user. I suppose an important question is now often = we see this actually failing, and in what circumstances: if there's a = moderate chance of it failing on low-memory machines under memory = pressure, it suggests we've gone wrong somewhere... One nice thing about = the non-wiring model is that it's pretty cheap in the common case, = whereas the new code is pretty expensive in the common case. Maybe this = doesn't matter too much. Robert=