In D27643#617767, @emaste wrote:

For reference, originally introduced in rS257079

In D27643#617738, @rlibby wrote:

I'm not an expert in the build, but it LGTM. I only wonder if there ought to be a common makefile for this and release/Makefile both to include.

In D27507#615492, @markj wrote:

In D27507#615239, @bdrewery wrote:

I think a dedicated iterator would be reasonable. I just wanted to avoid polluting the common case with checks needed to handle rare contig allocations.

In D27508#615133, @hselasky wrote:

Hi,

Can you explain this change a bit more?

gfp_t may contain bits which are not supported by the M_XXX flags and should be filtered away?

If you need to pass additional flags you need to update GFP_NATIVE_MASK .

--HPS

In D27507#615134, @kib wrote:

I wonder if it is better to move the retry policy into iterators instead.

• Take Mark's comment

• Move the fix out of the iterator.

• Set di_flags|=M_NOWAIT consistently

Thanks for working on this. I'll review+test soon.

The whole story for this is very longwinded. I'll just say that using lazyloading for the probe avoids the need for linking drti.o and is a better solution for libthr.
It's also all reliant on being an incremental build from before the recent incremental fixes to libdtrace. I still need the libdtrace bootstrapping in my work situation but makes no sense for FreeBSD yet.
All in all this change is incomplete and would make more sense to come in with most of the summary patch as well if it is ever needed.

The whole premise here is wrong. CCACHE_NODIRECT=1 avoids my problem. I'm not going to fix what's not broken. Sorry for the noise.

There is a catch with the direct mode: header files that were used by the compiler are recorded, but header files that were not used, but would have been used if they existed, are not. So, when ccache checks if a result can be taken from the cache, it currently can't check if the existence of a new header file
should invalidate the result. In practice, the direct mode is safe to use in the absolute majority of cases.

Yeah it seems to be ccache causing my problems and this change just forced a rebuild. META_MODE+filemon has the same flaw :-(.
So my reasoning is wrong.

I am perplexed why it finds libelf.h but not libproc.h.

In D17128#371823, @des wrote:

I would strongly recommend submitting the sshbuf_{get,put,free}_passwd() part of this patch upstream.

Brilliant!

The problem I see is that not everything will use this or the sysctl. Ports, Poudriere, nearly everything, are doing getenv("LOCALBASE"). Other places have things like LOCALBASE?= /usr/local. So then I wonder what the usefulness of it being configured in the kernel in the first place is as a user setting it won't achieve much.

This was just an optimization in rS322565 so there's no harm in losing it until we find a way to make it work. I found it was related to MK_PROFILE flipping back then.

Nice find!
I missed that the symlink installs didn't use $SHLINSTALLFLAGS back in rS322565. I banged my head on this problem for a long time with dhw@ hitting it daily.

Sorry about that. I didn't communicate my concerns in a proper way. (As noted in private email).
Here I am worried about quietly not installing headers leading to silent bugs like a downstream compilation using a header it finds in another directory instead.
I missed the build time assertion in bsd.incs.mk. That helps a lot to mitigate my concerns as it yells at people to fix it. Having taken a second look I support this and think the implementation is good too.
We have a similar problem with CONFS that causes make installconfig to take forever for mergemaster and etcupdate. It would be nice if that was worked into this too.

In all cases in fts.c, NULL is returned when FTS_STOP is set. The downstream fts is the problem, not FreeBSD or mtree.

Add comment

Move to local.meta.sys.mk

Please don't. This is such a huge niche micro optimization. -j1 isn't normal and I don't see this being worth the maintenance cost.

I had committed this prematurely and now reverted.

Building /usr/obj/usr/src/i386.i386/sys/SARAH/vfs_bio.o
--- vfs_bio.o ---
/usr/src/sys/kern/vfs_bio.c:3614:7: error: implicit declaration of function 'vm_page_lookup_unlocked' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                m = vm_page_lookup_unlocked(obj, OFF_TO_IDX(off + toff));
                    ^
/usr/src/sys/kern/vfs_bio.c:3614:7: note: did you mean 'vm_map_lookup_locked'?
/usr/src/sys/vm/vm_map.h:480:5: note: 'vm_map_lookup_locked' declared here
int vm_map_lookup_locked(vm_map_t *, vm_offset_t, vm_prot_t, vm_map_entry_t *, vm_object_t *,
    ^
/usr/src/sys/kern/vfs_bio.c:3614:5: error: incompatible integer to pointer conversion assigning to 'vm_page_t' (aka 'struct vm_page *') from 'int' [-Werror,-Wint-conversion]
                m = vm_page_lookup_unlocked(obj, OFF_TO_IDX(off + toff));
                  ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/src/sys/kern/vfs_bio.c:3624:5: error: incompatible integer to pointer conversion assigning to 'vm_page_t' (aka 'struct vm_page *') from 'int' [-Werror,-Wint-conversion]
                n = vm_page_lookup_unlocked(obj, OFF_TO_IDX(off + toff));
                  ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 errors generated.
*** [vfs_bio.o] Error code 1