> My kernel assumes a sane environment when it starts, which means that all
> the hairiness is in BBBB.  

IMO this is where it should be.

> BBBB is the bit that handles getting the kernel
> into contiguous physical memory, but I'd _really_ prefer it written in C
> so it can use libsa to load the kernel off an FFS disc and useful stuff
> like that.
Sounds like a good idea.

> [ea and eb]
> > I compiled in the mbuf alignment patch in the arm32 if_ea.c and if_eb.c
> > and they compile. I'm currently doing speed tests to see if there is a
> > significant performance gain/lossage but i dont think so really.
> 
> Ah.  I needed the patch because without it the NFS_BOOT_DHCP stuff simply
> didn't work.  Does it work on arm32 without the mbuf alignment fixed?  
> This may be a consequence of my compiler changes.

The compiler will inline short bcopys (well, probably memcpys) up to 64 
bytes if it knows the alignment is sufficiently strict.  If the data isn't 
aligned to this (but the compiler has been, in effect, told that it is; 
then the inlined code will copy the data incorrectly.

In the ARM32 world this optimization is disabled for the mbuf structures 
because we cannot assume they are sufficiently well aligned (NetBSD used 
to fail in several places if we assumed the alignment; though they should 
all now be fixed).  Unfortunately, turning alignment of such structures 
back on again will introduce a binary incompatibility, so we can't to this 
until we switch to elf.

> 
> > just ran the test... no noticable change ... is it for your bcopy() is
> > only word aligned?
> 
> My bcopy is the arm32 one (with the calling convention changed to
> APCS-26).

You aren't likely to see any noticeable speed up unless the compiler can 
take advantage of the known alignment.