On 26 Jan 2011, at 23:41, m...@freebsd.org wrote:
> Upon further consideration, I don't think sbuf_new_for_sysctl() should
> be doing the wire. Whether the buffer needs to be wired or not is up
> to the implementation of the individual sysctl; *most* of them will be
> holding a lock when doing s
On Wed, Jan 26, 2011 at 1:19 PM, Robert N. M. Watson
wrote:
>
> On 26 Jan 2011, at 21:14, m...@freebsd.org wrote:
>
>>> The kinds of cases I worry about are things like the tcp connection
>>> monitoring sysctls. Most systems have a dozen, hundred, or a thousand
>>> connections. Some have half a
On Wednesday, January 26, 2011 4:14:15 pm m...@freebsd.org wrote:
> On Wed, Jan 26, 2011 at 1:10 PM, Robert N. M. Watson
> wrote:
> >
> > On 26 Jan 2011, at 18:29, m...@freebsd.org wrote:
> >
> >>> I suppose an important question is now often we see this actually
failing
> >>
> >> I don't believe
On 26 Jan 2011, at 21:14, m...@freebsd.org wrote:
>> The kinds of cases I worry about are things like the tcp connection
>> monitoring sysctls. Most systems have a dozen, hundred, or a thousand
>> connections. Some have half a million or a million. If we switched to
>> requiring wiring every p
On Wed, Jan 26, 2011 at 1:10 PM, Robert N. M. Watson
wrote:
>
> On 26 Jan 2011, at 18:29, m...@freebsd.org wrote:
>
>>> I suppose an important question is now often we see this actually failing
>>
>> I don't believe we've ever seen a memory failure relating to sysctls
>> at Isilon and we've been u
On 26 Jan 2011, at 18:29, m...@freebsd.org wrote:
>> I suppose an important question is now often we see this actually failing
>
> I don't believe we've ever seen a memory failure relating to sysctls
> at Isilon and we've been using the equivalent of this code for a few
> years. Our machines ar
On Wed, Jan 26, 2011 at 9:55 AM, Robert N. M. Watson
wrote:
>
> On 26 Jan 2011, at 17:12, m...@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 period
On 26 Jan 2011, at 17:12, m...@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).
>
> I'm not
On Wed, Jan 26, 2011 at 1:37 AM, Robert Watson wrote:
> On Tue, 25 Jan 2011, Matthew D Fleming wrote:
>
>> .Dv SBUF_AUTOEXTEND .
>> .Pp
>> The
>> +.Fn sbuf_new_for_sysctl
>> +function will set up an sbuf with a drain function to use
>> +.Fn SYSCTL_OUT
>> +when the internal buffer fills.
>> +The sy
On Tue, 25 Jan 2011, Matthew D Fleming wrote:
.Dv SBUF_AUTOEXTEND .
.Pp
The
+.Fn sbuf_new_for_sysctl
+function will set up an sbuf with a drain function to use
+.Fn SYSCTL_OUT
+when the internal buffer fills.
+The sysctl old buffer will be wired, which allows for doing an
+.Fn sbuf_printf
+while
Author: mdf
Date: Tue Jan 25 17:39:52 2011
New Revision: 217830
URL: http://svn.freebsd.org/changeset/base/217830
Log:
Document sbuf_new_for_sysctl(9).
Pointed out by: lstewart
Modified:
head/share/man/man9/Makefile
head/share/man/man9/sbuf.9
Modified: head/share/man/man9/Makefi
11 matches
Mail list logo
