> NetBSD/i386 uses a compile-time-constant number of kernel page table
> pages (defined by NKPDE) to map the kernel.  When it runs out, it
> dies.  This typically happens on machines with lots of memory, or in
> other situtations where you end up wanting to map lots of physical
> memory into kernel space.  (It usually happens on machines with lots of
> memory because they have lots of buffers, which need to be mapped into
> the kernel.)
> 

Wait, is this the total number of pages occupied by the kernel+data?

> It's worth noting that BSD/OS (from BSDI) apparently solves this
> by picking the number of kernel page table pages at boot time, which
> means that (assuming their formula for the amount of mapping into
> kernel space you can do is correct), they shouldn't crash by running
> out of kernel page table entries.
> 

It would be cool if this number could be adjusted on the fly.

In fact, there are lots of cool things that could be done with the
kernel:

1) Resizable tables, to eliminate "q: My machine crashed with x message",
"a: Adjust this define and recompile" problems. How about, instead of
using arrays, use linked lists of arrays? The arrays could be in fixed
sizes, with a linked list of the chunks. Then references to the arrays
could be replaced with macros that walk the tree if needed. If the
chunks of array are large enough very little speed hit would be incurred.

2) Paging the kernel out, so a GENERIC kernel could be used, and after
probe time just kick the unneeded drivers out of memory. What happened
to lkm filesystems? I thought somebody was working on lkm msdosfs,cdfs,
etc. Question: How hard would it be to have *all* filesystems lkmable,
and be able to link them static if needed? I mean, on a regular boot
bffs is certainly needed, but is nfs? The reverse: Why have bffs in
a kernel that is nfs booted? Or why not be able to boot from an msdos
disk, the way linux can?

3) The major/minor number lkm dev problem. How about a kernfs-like lkmdevfs
thingie that union mounted on top of /dev, so lkm devices "just show up"?

4) Having the kernel know what boot kernel image was used. How does
OSF/1 do this? How about pass the name into the kernel as an arg on
bootup (by the loader)? Then pass that name to libkvm. Then how do you
deal with /dev/reload? Not 100% surefire, but it's an idea?

5) How about a kernel that could recognize certain errors at not being
misson-critical panic attack problems, and just disable certain parts
of the kernel on error? Like debugging an lkm filesystem: if the author
screws up, no need to panic the system, just kill that lkm.

6) Convince the Computer Science department here at NCSU that me working
on this stuff is more worthwhile than me in classes designed for students 
that touched their first computer as a freshman. If somebody could come
up with a workable solution for this one, I'll be your friend for life ;).

Ideas? How about sending responses to tech-kern?

XCOMM --------------------------------------------------------
XCOMM Kevin P. Neal, Sophomore CSC/CPE     kpneal@eos.ncsu.edu 
XCOMM North Carolina State University      kevinneal@bix.com
XCOMM --------------------------------------------------------