> I know nothing at all about Java, but there's no technical reason why the
> C compiler can't compile to p-code (other than the time to write a new
> back-end... WHEE).  The kernel then needs to include a p-code interpreter,
> which need not be very large if the p-code isn't very complicated.

You are probably aware that a couple of research (and may be
even a commercial) operating systems do something similar
but they go one step further and generate machine code on
the fly (also known as runtime code generation or RTCG).
This technique has even greater potential for optimization
(because more info. is available at runtime) but we are not
there yet.

I believe Java also does this sort of RTCG which is one
reason I am excited about it.  May be its intermediate
language can be used as a C intermediate language so that
we can use Java's backend(s).

At any rate, this seems like an overkill for what we want to do.

> (The p-code /sbin/init described above does so little with so much kernel help
> that kernel probably ought to just go find /sbin/init.ARCH itself anyway.)

Bingo!  May be the kernel should first look for /sbin/init
and failing that look for /sbin/init.${ARCH}.
/sbin/init.${ARCH} can then just do a chroot to /${ARCH}.

I too am not in favor of modifying namei to do something
special on seeing a magic token.