>Are there plans to get lkms working soon?  Or am I confused and they
>already work?

I personally have no plans to get LKMs working in the near future.
i'd like to see them but there are other things I find more important,
like finishing the user-land sharedlibs, getting X11R6 working
(including server) and the r4000 support.   I can fall back to
statically-configured kernels until then.

If you would like to take this on I would be delighted.

Here's a sketch of what has to be done:
	* Change the existing binutils so that it can read, and
	  link against, a.out files.

	* Rework  modload to  construct a command line for
	  a new binutils ld (e.g., 2.6, 2.7 or the one in the snaposhot)
	  rather than the ancient GNU ld syntax it currently uses;

	* rework modload to read ELF (and maybe ECOFF too, one day)
	  symbol information out of an LKM.
	  The current modload source just uses a.out.h macros directly;
	  if I were doign this and had the time, I'd replace those
	  with a layer of indirection over a small library.
	  See how  nlist(3) does support for a.out, ECOFF, and ELF;
	  I'm thinking of something vaguely like that.

	* change the size and entrypoint calculations to use
	  the new `library' above. 
	  Or hardwire them to  ELF_ macros. I guess the code
	  should support either ELF32 or ELF64, supporting both
	  in one program may need some thought.

Another (ghastly, but easier!)  approach would be to build LKMs and
then convert them into a.out format.  If you build GNU binutils with
both elf and NetBSD a.out support that should work.  I haven't pursued
it because another thing I'd like to do is revamp the bootblocks to
boot kernels in ELF format, rather than converting to a.out.

The conversion was done as a least-pain path years ago, before NetBSD
had any support for non-a.out formats in kvm_mkdb, libkvm, nlist, etc.
That's no longer the case, and there's really no good reason to keep
using a.out-format kernels.   Unless by some chance it makes LKMs
easier.

--Jonathan