> (3) PS_STRINGS was the same for all the m68k ports, which it's not.
> (4) the kernels were loaded at the same addresses, so that kernel-related
>     utilities that need it are portable.
> (5) the ports handled the 68040 similarly, so that libkvm didn't need
>     #if's.
> 
> There are probably other problems, too.

yes, i know.  however, the more incentive to fix them, the more likely
they'll be fixed.

also various kmem-juggling things (e.g. pstat, or whichever one gives
tty info) need to be frobbed to deal with all m68k ports...

> BTW, running 4k executables on a 8k machine only needs to be a *tiny*
> bit less efficient that running 8k executables, even in the worst case.
> I've already discussed why this is so.

umm, except that e.g. you end up having a page that contains read (not
mapped) data, and isn't sharable...  so if you're using lots of copies
of the same 4k executable (say, a shell, or something), then you lose.

> Also, the 4k compatibility code *has* to be written, in order to run old
> 4.4BSD and NetBSD executables on the hp300.  Once that's done, there's
> hardly any reason to switch the hp300 port, until the other problems are
> resolved.

That's not entirely clear, but i'm not going to say that it's not reasonable.


cgd