Add KPI to dynamically register pager type

[kib]

Summary

Remove OBJT_SWAP_TMPFS, dynamically register pager type for tmpfs on vfs_init

[mjg]

Is the functionality really worth it? There are also no provisions to refcount pager users, so there is no way to indicate it can't be safely unloaded. tmpfs is enabled in GENERIC, so by default the fuctionality wont be used.

Even if the patch is to go in, perhaps it would be sufficient to skip automatic registration and explicitly enumerate all supported pager types to save on some complexity.

My $0,03.

[kib]

In D30168#677456, @mjg wrote:

Is the functionality really worth it? There are also no provisions to refcount pager users, so there is no way to indicate it can't be safely unloaded. tmpfs is enabled in GENERIC, so by default the fuctionality wont be used.

For tmpfs it is clearly the presence of mounts that is equal to presence of users.

GENERIC is not the end of the world, for instance all my kernels do not include tmpfs (I use some kind of MINIMAL, but less than it)

Overall, dyn registration incurs zero runtime overhead, and makes it easier to create new types of pagers. Although it is non-trivial to write correct pager, I will not be surprised if something new appears there once we make it less troublesome. One immediate candidate would be to make largepage shm use real pager instead of patching phys.

Even if the patch is to go in, perhaps it would be sufficient to skip automatic registration and explicitly enumerate all supported pager types to save on some complexity.

[mckusick]

I think that this change provides a useful cleanup of the VM system. As noted it makes it easier to create new types of pagers.

[markj]

sys/fs/procfs/procfs_map.c

170 ↗

(On Diff #88863)

So what should be done here? Can vm_object_kvme_type() be used?

[kib]

Implement forgotten chunk in pseudofs_map.

[markj]

sys/fs/tmpfs/tmpfs_subr.c

117 ↗

(On Diff #88963)

Why can't handle be used instead of the pager-specific field?

[kib]

sys/fs/tmpfs/tmpfs_subr.c

117 ↗

(On Diff #88963)

Correct use of the 'handle' field for non-anon objects is to pass handle to vm_pager_allocate(), which registers the object on the list of named pager-owned objects. Several places in vm/ assume that non-anon named object == obj->handle != NULL.

So there are problems.

1. We do not need the name for tmpfs objects, we never look up object by handle because we have node.
2. Handle may become NULL when the vnode reclaimed, and assigned back some different non-NULL value when vnode recreated.

The only meaningful and conforming value we can assign to handle there is tmpfs_node. But we do not need neither that, nor 'named swap object' semantic.