Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Jan 2011 17:55:09 +0000
From:      "Robert N. M. Watson" <rwatson@freebsd.org>
To:        mdf@FreeBSD.org
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r217830 - head/share/man/man9
Message-ID:  <12EB1BEA-F0AF-4B2A-AFEB-9C38C7994FA8@freebsd.org>
In-Reply-To: <AANLkTimqyPYah5=yWHVxf3Us4=cBYKGkb0oyAE%2B7R-%2Bt@mail.gmail.com>
References:  <201101251739.p0PHdqKX044842@svn.freebsd.org> <alpine.BSF.2.00.1101260929430.44308@fledge.watson.org> <AANLkTimqyPYah5=yWHVxf3Us4=cBYKGkb0oyAE%2B7R-%2Bt@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12EB1BEA-F0AF-4B2A-AFEB-9C38C7994FA8>