Now, Nathanial Sloss has made a stab at this, providing several implementation choices. Challenges in the task are that sounds with different quality (sampling rate, mono/stereo etc.) need to be brought to one common quality before mixing and passing on to the actual audio hardware. Further fun is added by the delay this process adds. See the discussion on tech-kern for all the gory details!

More information: PaX, PIE, ASLR, MPROTECT.

 - I cleaned up the asm code and fixed several comments, which makes the
   boot process much easier to understand.
 - I fixed the alignment for the text segment, so that it can be covered by
   more large pages [1] - thereby reducing TLB contention.
 - I fixed a bug in the way the secondary CPUs are launched [2], which
   caused them to crash if they tried to access an X-less page.
 - I took rodata out of the text+rodata chunk, and put it in the data+bss+
   PRELOADED_MODULES+BOOTSTRAP_TABLES chunk [3]. rodata was no longer large
   page optimized, and had RWX permissions.
 - I retook rodata out of the rodata+data+bss+PRELOADED_MODULES+
   BOOTSTRAP_TABLES chunk, and made the kernel map it independently without
   the W permision [4].
 - I made the kernel map rodata without the X permission, by using the NOX
   bit on its pages [5] (now that the secondary CPUs could handle that
   properly).
 - I took the data+bss chunk out of the data+bss+PRELOADED_MODULES+
   BOOTSTRAP_TABLES chunk, and made the kernel map it independently without
   X permission [6].
 - I made the kernel remap rodata and data+bss with large pages and proper
   permissions [7] - which reduces once again TLB contention.

 - on non-PAE i386, NOX does not exist. Therefore the mappings all have an
   additional X permission. To benefit from X-less mappings, your CPU must
   support PAE, and your kernel must be GENERIC_PAE.
 - the segments are not large-page-aligned, which means that probably some
   parts of the segments are still mapped with normal pages. It is still more
   optimized than it used to be, but not as much as amd64 is.

Besides my essay on What makes an operating system portable, there was a posting to the netbsd-advocacy mailing-list that goes into a few details on NetBSD's current state of portability. The posting lists a number of reasons why the author considers NetBSD to be portable, including the low effort to start new projects, central maintenance in one source tree, and the efforts from machine-independent changes to all ports.

After reading about people doing research on how to assess "security" of operating systems by counting number of exploits and how quick they are patched, I wonder if there are some metrics out there to also put "portability" into numbers.

I tested growing a partition in FFSv1 and FFSv2 from 1GB to 4GB and the process was smooth (and fast); after this I ran 'fsck_ffs -yf /fs' and it found one error that was fixed correctly.'' For more information, including where to get the code and what to test, see Juan's posting.

There were a few attempts to get logical volume management (LVM) onto NetBSD, which were not successful so far. This may change in the future, and when flexible handling of storage volumes, with growfs(8) will be useful to manage FFS/UFS file system sitting on top of them.

For more information on the SEIL Engine, see IIJ/SEIL's homepage (Japanese). and PDF brochude (English).

Also, for some impression of the SEIL/X machine on the geek level, there's dmesg output of the machine available.