I'm fine with either check (<= 0 or @cem's version) with the same change applied to linux32_sysvec.c

In D15952#337749, @chuck wrote:

I'm only finding two copies: sys/i386/linux/linux_sysvec.c and sys/amd64/linux/linux_sysvec.c but have updated the patch to fix those copies.

We will also need to address the four copies of linux_trans_osrel (but after further investigation if desired, I have not checked exactly how the value they calculate is used).

In D15952#337697, @cem wrote:

Right, I suggested using LINUX_KERNVER() to do this in my initial comment :-).

Ah, top level Linux Makefile emits a definition of KERNEL_VERSION using shifts.

Ah, I see the comment in the bug now - yes, if Linux uses shifts we should too. It would be good to put a reference in the commit that mentions the Linux macro/etc. that calculates it though.

In D15952#337607, @cem wrote:

Ed, can you explain it in a little more detail?

In D15858#336639, @chuck wrote:

In D15858#336162, @emaste wrote:

See linux_map_osrel

This probably fits better with the existing code, and I'm inclined to move that direction. Is using linux_kernver() the way to access this value?

I'm still getting the handle of the process here. In my local repo, these are two separate git commits, are you saying the correct way to do this would have been two separate arc diff commands for each of my git commits?

I took care of the NFIT man page addition in rS335459 - it was my fault :)

In D15904#336964, @mat wrote:

What matters is that it is available on all supported releases :-)

Another option: upon discussion with @dim we will likely end up installing llvm's llvm-objdump as objdump. It's broadly compatible, but the output format etc. might be slightly different.

On second thought I'm not sure about this: --print-file-name options typically prefix all output lines with the file name.

This looks fine to me. It's probably worth adding a comment explaining the use of ${NONEXISTENT} though.

In D15904#336884, @mat wrote:

Mmmm,

$ readelf --print-file-name -r /usr/bin/mktemp
readelf: unrecognized option `--print-file-name'

Reported in the PR -- nm might be more useful for this script.

LGTM

Would it make sense to set some new variable based on TOOLS_PREFIX, MK_LLD, MK_LLD_BOOTSTRAP so that the same expression doesn't need to be repeated?

Looks ok

(email followup to copyright holders sent Jun 18)

See linux_map_osrel

Minor tidyup

Also support V2. It's identical to V3 except that in Linux it produces a warning if used.

Update copyright and minor cleanup

I like the idea, but I think the version comparison ought to be simplified and made more general. What do you think about parsing the version into a __FreeBSD_version style single integer in the sysctl handler and simplifying any comparisons of the value?

I did this in my tree this morning after our IRC discussion but went out for the afternoon. Committed after IRC discussion with @allanjude

In D15827#334689, @rgrimes wrote:

I actually worry less about man page DEPRECATION, and more about having the binary spit something out so anyone using it for who knows what gets a heads up that it is/may be going away soon.

perhaps this for deprecation notice:

Index: usr.sbin/asf/asf.8
===================================================================
--- usr.sbin/asf/asf.8  (revision 335216)
+++ usr.sbin/asf/asf.8  (working copy)
@@ -37,6 +37,15 @@
 .Op Fl o Ar outfile
 .Op Fl X Ar suffix
 .Op Ar modules-path Op Ar outfile
+.Sh DEPRECATION NOTICE
+The
+.Nm
+utility is not present in
+.Fx 12.0
+and later.
+The
+.Xr kgdb 1
+debugger handles kernel module state internally.
 .Sh DESCRIPTION
 By default,
 .Nm

Objdump removal tracking pr in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229046

Committed to rendered man page in rS335219.

In D15237#334538, @andrew wrote:

How will this work if we decide to add linux32 on arm64? I expect we will need to implement the legacy syscalls there.

LGTM

It might be worth moving the clarification you provided in response to my query into a comment above linprocfs_dominfree.

rS329166

Change seems sensible to me.