svn commit: r279932 - head/sys/vm

[Ian Lepore]

On Fri, 2015-03-13 at 13:19 -0400, John Baldwin wrote:
> On Friday, March 13, 2015 10:14:27 AM Ian Lepore wrote:
> > On Fri, 2015-03-13 at 06:24 -0400, John Baldwin wrote:
> > > On Thursday, March 12, 2015 05:24:51 PM Ian Lepore wrote:
[...]
> > 
> > In general I'm glad I got called away to an onsite meeting yesterday and
> > didn't get far with these changes, because the more I think about it,
> > the less satisfied I am with this expedient fix.  The other fix I
> > started on, where a new SBUF_COUNTNUL flag can be set to inform the
> > sbuf_finish() code that you want the terminating nul counted in the data
> > length just feels like a better fit for the overall "automaticness" of
> > how the sbuf stuff works.
> 
> Hmm, I actually think that it's a bug that the terminating nul isn't included
> when draining.  If we fixed that then I think that fixes most of these?
> The places that explicitly use 'sysctl_handle_string()' with an sbuf
> should probably just be using sbuf_len(sb) + 1' explicitly.  (Another
> option would be to have a sysctl_handle_sbuf() that was a wrapper around
> sysctl_handle_string() that included the + 1 to hide that detail if there is
> more than one.)
> 

Some of the uses of sbuf for sysctl use sbuf_bcat() for dealing with
binary structs, so we can't just assume that a nullterm should be added
and included in the buffer length -- there needs to be some mechanism to
say explicitly "this is an sbuf for a sysctl string" (and more generally
"this is an sbuf for a string where I want the nul byte counted as part
of the data" because that could be useful in non-sysctl contexts too,
especially in userland).

-- Ian