In D45058#1027959, @markj wrote:

Include missing headers sys/queue.h from vm/_vm_phys.h for TAILQ, and sys/param.h from vm/vm_phys.h for NULL so linux/io.h doesn't have to include them.

I think this part should be committed separately.

arch_io_reserve_memtype_wc is implemented using PHYS_TO_DMAP and pmap_change_attr but not all architectures have a DMAP and this doesn't match the upstream implementation.

Looking at Linux, the old version of this diff actually does partially match the implementation. If the platform doesn't have a direct map, or the PA range isn't backed by RAM, then it does nothing. Otherwise it updates the mapping type of the range in the direct map, presumably to avoid the UB that kib mentions.

I think what this function is supposed to do is check whether the PA range is covered by the vm_page_array and update the direct map if so, otherwise register a fictitious range. Perhaps this is best implemented in the VM system rather than the LinuxKPI?

In D45074#1027845, @dim wrote:

Does the cxa_thread_dtor::dso field serve any function after this change? I couldn't see any other references to it.

As I noted, I am not sure that vm_phys_fictitious_reg() KPI is prepared for such use. IMO it needs to be enhanced to check if the registering range is already backed by some vm_page_t storage and not create an overlap. Right now there are only minor piece of such care, for the case where the range intersects with vm_page_array[]. Otherwise the result is UB both for memattr use, and for consequent RBTREE manipulations.

Mentioning the supposed scope of use for flag in the review would be best. BTW if it is internal to vm allocators, why not call it M_VM_NOFREE?

u_long

Why not M_NOFREE?

Please upload patches with full context.

Can you upload the full context for the diff?

In D44271#1026288, @brooks wrote:

In D44271#1025583, @kib wrote:

Private versioning namespace should be filtered out, I think.

I think we want to know when that set changes even if we don't consider it part of the ABI, but I probably could be persuaded otherwise. I might want to make it optional so libraries can opt in and others opt out.

In D44910#1026299, @jhb wrote:

In D44910#1024125, @kib wrote:

Could the purpose of the new cpu method expressed as "move CPU state to PCB/thread save location in preparation for ..."? I think a comment like that would be due.

Where would you want that comment to go? Next to its prototype in <sys/proc.h>?

Grammar updates.

In D44306#1025639, @ashafer_badland.io wrote:

Do we have a good way to detect if we are building for a dynamic module or not during build? I looked for a macro that signaled that but couldn't find anything in kmod.mk.

Private versioning namespace should be filtered out, I think.

In D44306#1025524, @ashafer_badland.io wrote:

It seems the way it works is that THIS_MODULE is a NULL pointer during "builtin" (statically building modules into the kernel), and points to the struct module of the dynamically loaded module otherwise. I think we could do something similar where we get the current linuxkpi behavior (THIS_MODULE is null) if we aren't building a dynamically loaded module?

With that concern resolved I guess the question now is do we want to:

a) have __this_module magically resolve to the current linker_file_t, implementing module_put as jhb suggested (no wrapper struct, close to what the current revision is)
b) have some linuxkpi macro declare a struct module global, validate usage at module load time (similar to the previous version I linked)
c) maybe have the module loader allocate space at load time, placing __this_module there and filling it with a wrapper struct? Not sure how possible this is.
d) something else?

Of the options I think (a) is the simplest, but (c) would probably be the most robust. I'm not expert but happy to implement whatever you all suggest.

Do we need to put SPD tags in the added files?

In D44306#1023990, @ashafer_badland.io wrote:

Instead, it should be only resolved locally, causing undefined symbol error if attempt is made to reference it from kld without the module symbol (section ?).

Could you elaborate a little on what you mean by this?

There was an earlier version of this which used LKPI_DRIVER_MODULE to create a global variable for each lkpi module, do you mean something like that? It would be very easy to create the dummy struct module there.

https://github.com/freebsd/drm-kmod/pull/297

So overall this stuff is in principle incompatible with the code like memcmp(*a++, *b++, XXX) ?

Could the purpose of the new cpu method expressed as "move CPU state to PCB/thread save location in preparation for ..."? I think a comment like that would be due.