Would there be some fundamental problem in changing MSGBUF_SIZE from a compiled-in constant to a tunable that could be set at the loader prompt? (I'm _not_ suggesting that it be adjustable while the system is running.) The upside would be that, if someone needed a larger buffer temporarily to accommodate trace data from a mechanism such as kern.geom.debugflags, the size could be adjusted without having to rebuild the kernel. I didn't see any obvious downside from examining the 8.1-RELEASE code, but I could certainly have overlooked some subtle (or even blatant) reason why this would be a Bad Idea.
on 06/12/2010 07:20 perryh@pluto.rain.com said the following:> Would there be some fundamental problem in changing MSGBUF_SIZE > from a compiled-in constant to a tunable that could be set at the > loader prompt? (I'm _not_ suggesting that it be adjustable while > the system is running.) > > The upside would be that, if someone needed a larger buffer > temporarily to accommodate trace data from a mechanism such as > kern.geom.debugflags, the size could be adjusted without having > to rebuild the kernel. > > I didn't see any obvious downside from examining the 8.1-RELEASE > code, but I could certainly have overlooked some subtle (or even > blatant) reason why this would be a Bad Idea.I also don't immediately see why that wouldn't work. Can you try to come up with a patch? -- Andriy Gapon
On 16 January 2011 06:10, <perryh@pluto.rain.com> wrote:> Anyone had a chance to look at this? > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/060793.htmlTo ease testing on head I have regenerated the patch (against r216594): http://plukky.net/~pluknet/patches/msgbufsize.diff -- wbr, pluknet
On Sunday, January 16, 2011 12:24:27 pm Sergey Kandaurov wrote:> On 16 January 2011 06:10, <perryh@pluto.rain.com> wrote: > > Anyone had a chance to look at this? > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/060793.html > > To ease testing on head I have regenerated the patch > (against r216594): > http://plukky.net/~pluknet/patches/msgbufsize.diffThe one hunk involving tf_rip and PS_STRINGS in amd64 looks to be unrelated. Also, in subr_param.c, you can assume that MSGBUF_SIZE is always defined and always assign it as the initial value rather than having an #ifdef. Finally, I would adjust the wording in the manpage to not say that this modifies the MSGBUF_SIZE option, but that this tunable is the same as adjusting MSGBUF_SIZE. Other than that I think it is fine. -- John Baldwin