>        /sys/dev/audio.c line 1412 is currently
>
>        return i386_btop(vtophys((caddr_t)cb->start + off));
>
>        Its not protected in #ifdef anything, so breaks compiles on other
>        ports such as sparc... (unless you disable the audio device :)


The VM system currently uses MD cookies as the return value of d_mmap
driver entrypoints.  As such, it's not really possible to write MI
drivers that support mmap().  

I once suggested changing the d_mmap() entrypoint semantics so that it
returns a physical page address in the high-order bits, and protection
and "space" bits in the low-order bits.  (I still i386 patches for
that somewhere.)

I don't know if that's redundant in the new <bus.h> bus-dma world or not.

Short-term, the code is aimed at Linux emulation for, e.g., Quake, so
an #ifdef i386 around the entire audio_mmap() and around the single
call in audiommap() is probably enough.


I'm mildly suspicious that the ENODEV and ENXIO error codes from
audiommap() might end up causing the VM code to mmap() page zero.

I know a -1 return from a d_mmap() entrypoint is usually special-
cased to mean `bad offset'; are errno return values special-cased too?

Have those ENODEV and ENXIO return values actually been checked on,
say, a Sun4?