Fix sizes and wrong condition

Small test cleanup:

• mkdir mnt later, since we use it to signal that we need to try unmounting
• use a local for the path to check as a portability aid, other systems may be able to make different asssumptions about their filesystem layout and avoid needing to mount anything

In D51502#1295042, @zlei wrote:

I was writing tests and found

# jail -vc vnet vnet.interface=epair0a persist
jail_set(JAIL_CREATE) vnet=new persist
created
run command: /sbin/ifconfig epair0a vnet
ifconfig: 'vnet' requires argument
jail: /sbin/ifconfig epair0a vnet: failed
removed
jail -c vnet vnet.interface=epair0a persist

does not work on stable/14.

Nice fix !

Strip out the functional change- I'm going to commit that now. Use the PATH
approach we use in sysent to search for a flua to use between the system and
the bootstrap tools, just as we did in the sysent target. These two targets
knowingly pretend that STRICTTMPPATH doesn't exist, since they're developer
targets and I didn't want to add friction by requiring bootstrap-tools just to
rebuild these artifacts.

In D56365#1289902, @kib wrote:

An alternative for this O_SYMLINK is to define it just to O_PATH | O_NOFOLLOW, if it is not important to be able to open(<regular file>, O_SYMLINK | O_RDONLY) and be able to read from the resulting fd.
I would prefer that implementation instead of the reopening with EMPTYPATH for non-symlinks, but I do not know real-world usage patterns for O_SYMLINK.

I'm going to plan to commit this within the next day or so. I think linux's use of "stride" instead of size or shift for their naming of the bit is very telling, and their general range invalidation function seems to specifically just use PTE stride as well.

Nice catch

To be clear: I'm definitely not asserting that my interpretation of the language here is correct. In particular, I'm not confident that the second paragraph quoted means that it will only invalidate a 4K page if <va> isn't a superpage; I think the verbiage about 2M increment is clear, albeit a little verbose.

In D56386#1291602, @junchoon_dec.sakura.ne.jp wrote:

In D56386#1291600, @kevans wrote:

In D56386#1291595, @junchoon_dec.sakura.ne.jp wrote:

BTW, isn't bump of PORTVERSION or PORTREVISION needed as of codebase (in gnulib) changes?

Looking into commit history, especially of the first one at svn revision 559542, PORTREVISION seems to be preferrable.

https://svnweb.freebsd.org/ports?view=revision&revision=559542

You don't need a PORTREVISION bump to address build failures, unless the failures weren't across the board (e.g., worked fine on x86 but not arm64) -- there wouldn't be any functional packages, so everyone will naturally try to rebuild it. The PORTVERSION here reflected the shlib version, so it's already not very meaningful (and the ABI won't have changed)- I would be inclined to leave it alone and think about the version independently of this change in particular, since it's a more general problem that we have no idea what version of gnuilb any particular libgnuregex was built against.

What I meant was that this build breakage is caused by acutal code updates on gnulib that this port copies installed files from to build. So the bump is not for fixing build but for code updates corresponding to 20260127 at commit ports 929d989d32b56f3968371e6cd311ab9e9bd94a0d.

Note that bumps for every gnulib updates are not needed, but in case that files used for this is actually updated regardless build failures happenes or not.

In D56386#1291595, @junchoon_dec.sakura.ne.jp wrote:

BTW, isn't bump of PORTVERSION or PORTREVISION needed as of codebase (in gnulib) changes?

Looking into commit history, especially of the first one at svn revision 559542, PORTREVISION seems to be preferrable.

https://svnweb.freebsd.org/ports?view=revision&revision=559542

In D56386#1291241, @arrowd wrote:

Sorry for breaking it in the first place. I have no idea how I missed it when going over gnulib dependents.

thanks, that's nicer than what I was about to do after playing whack-a-mole with this path for a while.

In D52824#1286527, @des wrote:

@kevans can this be safely merged to 15 as well?