> Date: Thu, 4 Jan 1996 23:36:31 -0500
> From: "Chris G. Demetriou" <cgd@netbsd.org>
> Reply-To: cgd@netbsd.org

> >Number:         1891
> >Category:       kern
> >Synopsis:       kernel msgbuf has fixed size; pages can be partially wasted.
> >Confidential:   no
> >Severity:       non-critical
> >Priority:       medium
> >Responsible:    kern-bug-people (Kernel Bug People)
> >State:          open
> >Class:          change-request
> >Submitter-Id:   net
> >Arrival-Date:   Fri Jan  5 00:05:02 1996
> >Last-Modified:
> >Originator:     Chris G. Demetriou
> >Organization:
> Kernel Hackers 'r' Us
> >Release:        NetBSD-current as of January 4, 1996
> >Environment:
> System: NetBSD sun-lamp.pc.cs.cmu.edu 1.1A NetBSD 1.1A (SUN_LAMP) #19: Thu Jan 4 20:42:03 EST 1996 cgd@sun-lamp.pc.cs.cmu.edu:/usr/src/sys/arch/i386/compile/SUN_LAMP i386
> 
> 
> >Description:
> 	The current definition of the kernel message buffer is fixed at
> 	4k in size.  This is annoying on machines with a hardware page
> 	sizes > 4k, because:
> 		(1) it's relatively hard to make use of the rest of the
> 		    page being used for the message buffer, and
> 		(2) given that you're wasting the space, having a too-small
> 		    dmesg buffer is _very_ annoying, if your dmesg output
> 		    is the only easy way for you to get crash information.
> 
> 	Similarly, given the current definition of msgbuf, you can't
> 	devote multiple pages to the message buffer, even if you want to.
> 	System developers might want a larger (potentially much larger;
> 	i'd not mind 32k...) message buffer, and it might be nice for ports
> 	to provide it as a compile-time option.

I have one request related to this topic.  I would like to be able to
control the actual size of the message buffer using a macro definition
in the port-specific param.h file.  It was not clear to me whether the
changes proposed in this PR allow the size to be defined by each port.
(I suspect that was true, but want to make sure.)

On the sun3, I put the message buffer in the first page of memory,
(which is otherwise wasted) because that allows the message buffer
contents to be preserved across reboots.  However, the PROM appears to
use a few bytes at the very beginning of that page, therefore I would
ideally like to make the message buffer slightly smaller than one page
(8K-32 bytes?) and position it aligned at the end.

Gordon