Quoting Thor Lancelot Simon,

> This just doesn't seem right to me, any of it.  If the user chooses to
> override certain values like bufpages, nbuf, nkpde, or SHMMAX, we ought to
> adjust the maximum sizes of the larger structures to accomodate him.  Is there
> some hideously complicated reason we can't add up the sizes, and _then_ set
> VM_MAX_KERNEL_ADDRESS?  I realize that this would be a reasonably substantial
> reworking of locore, but it's mostly formulaic, right?

VM_MAX_KERNEL_ADDRESS is dependent on something that is rather a strict
boundary: 32 bits. The kernel is mapped on top of the VA space, so
the upper limit it simply the 4 Gb limit.. You can't change that.

What you can change is VM_MIN_KERNEL_ADDRESS, by mapping the kernel lower,
so it has more room to work with. Currently, it is given 128 Mb to work with
(see KERNBASE), and so it snoops 128Mb off the user VA space. This can
be changed, but it's hardcoded (it has to be) into the kernel executable
itself.

Arguably, you could say that you don't care if you loose some more Mb
of VA space, since you don't care if you have, say, another 128Mb less
at a total of 4Gb. Which is true for normal applications; there may
be things out there that use a sparsely mapped VA space.

- Frank