seriously?

• acpidump(8): Add NFIT to manpage missed in r321298
• acpidump(8): Add ACPI LPIT (Low Power Idle Table)

I probably should alphabetize the man page entries...

Blocked by pre-commit hook:

Add sysutils/Makefile modification

Address comments.

Thank you for fixing up this document, it really needed it.

In D15905#337055, @avg wrote:

In D15905#337019, @cem wrote:

CK_SLIST when most of accesses are done under a lock is an unneeded overhead.

Can you elaborate on that overhead?

I mean that even if the list is accessed under a mutex the CK_SLIST operations would still use all the fences because they wouldn't know about the mutex.
Or if the code already has fences around a larger block that includes CL_LIST operations.
Maybe it's a trivial cost and nothing to worry about.

Adapt to the move of stand/geli to stand/libsa/geli.

In D15743#335115, @eric_metricspace.net wrote:

Some thoughts here:

[...]
This aside, my only comment is that I'd like to see an interface that could more easily tie in to an external key storage system, such as a KMS. I did something like this in my GELI work, and one of the precursor patches can be found here: https://reviews.freebsd.org/D12698. My EFI work always used the EFI KMS interface, and a "fake" in-memory KMS is provided for the cases where there is no genuine device. This could happen in a follow-on changeset, though.

Is this one not supported by wmt(4)? The elan touchscreen on my Thinkpad X240 (0x04f3 : 0x0140) works great with wmt(4), but webcamd used to lose touch-end events...

Links to patches emerged
Macros: https://reviews.freebsd.org/D15928
Quirks: https://reviews.freebsd.org/D15929

In D15905#337019, @cem wrote:

CK_SLIST when most of accesses are done under a lock is an unneeded overhead.

Can you elaborate on that overhead?

Some drive-by nits inline.

No functional changes. This is the previous patch with quirks and macros moved, as andrew suggested

In D15857#337018, @kib wrote:

In D15857#336986, @yanko.yankulov_gmail.com wrote:

I think John' idea was to move the block which sets the has_ptrace_fork variable to true, down to the code which acts on its true value. De-fact, eliminating the var, and removing one if().

OK, but as far as I can tell we will need p1's PROC_LOCK or the proctree_lock in order to check the PTRACE_FORK flag. Am i missing something obvious again :) ?

We can read it lockless, and re-acquire the proc lock if set to re-read under the lock. This is not much different from reading under the lock, remembering the result, then drop the lock and use the result.

Don't forget the _WANT_SEMUN change.

CK_SLIST when most of accesses are done under a lock is an unneeded overhead.

In D15857#336986, @yanko.yankulov_gmail.com wrote:

I think John' idea was to move the block which sets the has_ptrace_fork variable to true, down to the code which acts on its true value. De-fact, eliminating the var, and removing one if().

OK, but as far as I can tell we will need p1's PROC_LOCK or the proctree_lock in order to check the PTRACE_FORK flag. Am i missing something obvious again :) ?

• Use ${DISTNAME}
• Remove manual WRKSRC definition
• Use pkg-plist instead of PLIST_FILES

• Add missing tabs
• Use ${EXTRACT_SUFX} where appropriate

• Remove semarg from GETVAL, GETPID, GETZCNT, GETNCNT
• Initialize semvals in SETALL by first calling GETALL

I think John' idea was to move the block which sets the has_ptrace_fork variable to true, down to the code which acts on its true value. De-fact, eliminating the var, and removing one if().

In D15903#336408, @mat wrote:

The Makefile has badly ordered bits. Could you please read Chapter 15. Order of Variables in Port Makefiles and make the appropriates changes.

Also, could you use devel/arcanist, or at least generate a diff with full context like it does, with svn diff -x -U9999 or git diff -U9999.

In D15904#336964, @mat wrote:

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

Applied all the modifications suggested by @bcr . Thank you!
The line-breaking were a first attempt to handle too-long lines, your solution is far better. A couple of comments:

• Add a note about the ${NONEXISTENT} argument.

As the task is simple, the tool we actually end up using does not really matter.

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.

In D15904#336954, @emaste wrote:

In D15904#336884, @mat wrote:

Mmmm,

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

The option for readelf doesn't exist in HEAD yet, it's in review in D15908.

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 D15857#336018, @yanko.yankulov_gmail.com wrote:

Address 2 of the jhb comments.

Have no idea about moving other code around.