So what happen when somebody run 'mount -a' second time, with non-idempotent mount option + update ?

Grammar.
Add global restart counter.

In D18538#395222, @rlibby wrote:

@cem pointed out to me r340842 & r340843. @kib would you prefer we just
did the same to i386 as was done to amd64?

In D18346#394762, @scott.d.phillips_intel.com wrote:

In D18346#394755, @kib wrote:

I do not understand your fixation on the newbus attachment for SPA. Now you are trying to hide it under the root NVDIMM device, but again, I do not see any connection between the root and activation of SPA support. To get SPA used, we only need SPA entries from the NFIT table.

I'm looking for the right place to put the ownership of the SPA_mappings. It seems wrong to have them owned and managed by the geom init function when geom is becoming a separate thing with a separate lifetime that can be destroyed before the SPA_mapping is destroyed. Does that sound like a reasonable motivation, or are you saying that doesn't matter?

In a certain sense, I think the SPA ranges could be considered as resources provided by the NVDIMM root device, specifically when you look at it in connection with the _DSMs the root device provides (sec 9.20.7 in the acpi spec). Though like you say, they're not like SPAs are _CRS resources so I suppose that view isn't inherent in the way things are modeled.

I do not understand your fixation on the newbus attachment for SPA. Now you are trying to hide it under the root NVDIMM device, but again, I do not see any connection between the root and activation of SPA support. To get SPA used, we only need SPA entries from the NFIT table.

I clearly missed this in the original commit. Why do you need this special-case 'dot' behaviour ? Why cannot getfhat() behave same as openat(2) WRT NULL path ?

Asm versions of the mips swap() primitives would be less ugly, but I think this can be taken care of by the mips people.

If it compiles, fine with me.

In D18346#392749, @scott.d.phillips_intel.com wrote:

In D18346#392735, @kib wrote:

What do we need ? I see that we need a unique unit number (currently punned by reusing the SPA index) and a way to list all SPAs at the unload time, to destruct them. Would be a global list of all SPAs enough for the later ?

That, and then later a per-spa list of namespaces and the corresponding code to handle their discovery/creation/deletion/etc

In D18346#392730, @scott.d.phillips_intel.com wrote:

In D18346#392701, @kib wrote:

Why do we need newbus attachment for SPAs ?

For ACPI-enumerated NVDIMMs, creating the devices is more or less natural since they represent physical objects that exist in the chassis. But SPAs are purely software constructs, which newbus devices seems to only tunnel the calls to init_ine()/fini_one().

I created new devices to not need to reinvent lifecycle tracking. While we don't support it yet SPAs can come and go dynamically when dimms are hotplugged. Also in the future SPAs will have namespaces which will be variable in number and can come and go dynamically.

I agree that SPAs aren't really like devices, but more precisely like resources provided by the NVDIMM root device, but they could reasonably proxy some operations to either the nvdimm devices or the nvdimm root device (like writes to flush hint addresses on nvdimms, or provide error information via the root device's address range scrub functionality). Providing some operations from a somewhat virtual SPA or namespace device would let userspace not have to reconstruct which dimms compose a SPA, or what address range of a SPA make up a namespace.

So I think those reasons are compelling, but I can understand that it's a bit weird. If you're not convinced then I can go back to tracking SPAs not as devices, but in that case we will need to implement a fair bit of what bus can already provide us.

Why do we need newbus attachment for SPAs ?

I think this can be changed to avoid procid_lock at all.

Peter. could you please take the diff and run it through stress2 ?

declErations, both it the title and in the text.

I think that our private export is too large. Ideally it would be trimmed down to the symbols used by libthr.

Disable clustering if map is limited by max_addr.

preserve->gap.
Comment update.

Reword comments.
Rename variable and symbol.
Remove dup assignment.

In D18423#392130, @emaste wrote:

Also, formally architectures can have different -fPIC and -fPIE ABIs, so perhaps we really need libXXX_pie.a, and e.g. libc_pic.a and libc_pie.a simultaneously.

Do you have a reference for this? At least for any architecture relevant to us today I don't think this is a practical case, so perhaps we ought to build _pic.a for PIE use for now, with a comment in bsd.lib.mk?

-fPIE code does not need to redirect all its external symbol accesses through GOT/PLT. This does not matter for x86 at compile time, only at the link time, but it might give an opportunity to optimize for other arches. Also the default TLS model might be different.

In D18423#392116, @emaste wrote:

Presumably we should build INTERNALLIBs and PRIVATELIBs as both libfoo.a and libfoo_pic.a (or some similar scheme) and choose the appropriate one when linking the binary. I don't know how far down that path we want to go though.