vm_mmap: Remove obsolete code and comments from vm_mmap()

[markj]

Summary

In preparation for removing OBJT_DEFAULT, eliminate some stale/unhelpful
comments from vm_mmap(), and remove an unused case. In particular, the
remaining callers of vm_mmap() in the tree do not specify OBJT_DEFAULT.

It's much more common to use vm_map_find() to map an object into user
memory, so rather than adjusting vm_mmap() to handle OBJT_SWAP objects,
let's further discourage its use and simply remove OBJT_DEFAULT
handling.

[kib]

sys/vm/vm_mmap.c

1495

Should this be an assert instead, then?

[markj]

sys/vm/vm_mmap.c

1495

I think that would be a bit too unfriendly. This is an external interface, not just for the VM, so IMHO it's better to check for unexpected cases and signal an error.

[kib]

sys/vm/vm_mmap.c

1495

I do think that assert would be the right reaction, esp. for external consumers. It is somewhat naive to expect them to correctly handle VM KPI and errors. If you state that the function only handles device and vnode objects, then we might as well be more vocal about it.

But I do not insist.

BTW, should managed device pager objects be allowerd there?

[markj]

sys/vm/vm_mmap.c

1495

It is somewhat naive to expect them to correctly handle VM KPI and errors. If you state that the function only handles device and vnode objects, then we might as well be more vocal about it.

This error will only occur as a result of a programming mistake. If the caller does not check for errors at all, then it will probably panic the system anyway. If it does check for errors, then any testing of the code will uncover the bug. We do not panic for other invalid parameters (size == 0, foff & PAGE_MASK != 0, etc.), so it makes sense to me to check for an invalid handle_type the same way.

BTW, should managed device pager objects be allowerd there?

Note that the object type passed to vm_mmap() is effectively a hint, it does not have to match the type of the returned object. So a caller can specify OBJT_DEVICE and receive a OBJT_MGTDEVICE object in response. We could include OBJT_MGTDEVICE in the list of cases, but doing so does not provide any new functionality.