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)
> 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.
> 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.
> Any non-ENOMEM failure from vslock() presumably would also have been a
> failure from SYSCTL_OUT and this does get squashed, perhaps
> 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.