I don't understand much of it, but I can confirm that the last commits fixed the problem I noticed with signals sent in syscallret().

I realized I probably shouldn't update the diff just for small changes... it's disruptive. Especially for a large diffs. Sorry about that!

Minor cleanups.

In D35116#795966, @brooks wrote:

Overall this change seems generally well contained for something that touches most syscalls. There are a few things that seem stray that I've noted.

I'm a bit worried about adding an on-by-default (we enable MAC in GENERIC for mac_ntpd) branch and function call to many, if not most, syscalls. Should the SY_CAP bits be under MAC or under a separate define? Presumably your goal is to move toward something usable with GENERIC so that would argue for not adding a separate knob.

Huh now that it got mentioned, it's a little bit worrying that it can trigger reads internally (even if the application shouldn't be able to get the data). Could something bad happen from some read side-effects somehow?

In D34903#791146, @emaste wrote:

Noted by Math Ieu in D34761. (Please let me know what name to use in the commit message.)

In D34761#789689, @brooks wrote:

A few thoughts about integration with syscalls.master:

• The if SYSFIL values aren't in syscalls.master they people won't remember to add them. This happened all the time with CAPENABLED annotations when it was in a separate file.

In D34761#788699, @markj wrote:

I just left some comments based on reading the code, I don't have a lot to say about the high-level design yet. It would be nice to see the new MAC handlers mentioned in your review description.

Some vague and not-very-actionable comments: we have a lot of new terminology here: curtain, sysfil, restricted mode, veiled. I wonder if it could be simpler. I'm also not sure how much benefit we get from making capability mode a special case of "restricted mode"; I also wonder a bit if MAC could be extended to handle more of what sysfil and restricted mode are doing.

Hard to say. It would make sense and IIUC it's what Linux does (though there are other incompatibilities there already and it treats options with an without dashes differently (its -a excludes session leaders for some reason, but the "BSD style" option without dash does not)).

Added a bzero() in kerneldumpcomp_write_cb(). Seemed a bit better to do it there. Not sure though.

Yeah that's better.

Change some more variables to bool in smbfs_vnops.

Change some ints to bools in fuse_vnops.c. No other changes.

Updated to use uint64_t instead of u_int64_t. No other changes.

I don't see any problems with the new version.

I've been using this and noticed no problems with both BIOS and UEFI boot. And now "currdev" matches "loaddev".

Updated for 13-CURRENT.

I don't notice any problems apart from that minor thing.

Restored the previous behavior of showing "***" when the number is too large instead of a truncated (and possibly misleading) humanize_number() output. It's not great but it's not worse than it was before.

Noticed a bug. Some calculations were sometimes being done with 32 bits integers and overflowing.

There are other problems with systat -vmstat as we talked about on IRC. I'm going to create another diff and add you guys as reviewers if you don't mind. I'm sure that this patch is correct after spending more time with it and it's very small so I'll leave it as is to not lose it. The other changes might be more problematic.

Still had this in my tree, updated for 13-CURRENT.

I think this just broke make world because libmemstat needs to be updated for this.

Forgot to add the new stand/efi/loader/help.efi file. There's no EFI-specific help yet but there could be.

Alright I couldn't let this go. Here's my attempt to fix it correctly with as little changes as possible. This installs a different help file for the EFI and non-EFI loaders.

wrt to the help files being installed multiple times, kevans already figured it out, but just to make it clear, the loader has some architecture specific help files but they also don't work.

Also, I just did a make world to test this patch (even though it's probably not fully correct) and there were no apparent problems apart from loader.help getting installed multiple times (once for all of the loader variants).

Just did a test booting in non-UEFI mode and then loaddev is set the same as currdev here. So the second problem seems to be specific to the EFI loader.

In D21006#455769, @dougm wrote:

Call swapon(2) after trimming, but before closing the trimming fd.

Probably not safe to start trimming the swap device *after* the kernel has been told to start using it for swapping (even if the window is probably small).

Don't mind me, just enjoying my very fast cmp (and wc -l).

Some cleanups, added a wc test case, fixed a cmp test case, fixed some wc logic that made it avoid its (already existing) fast path on STDIN.

In D16998#362748, @mmacy wrote:

Ok. I just read the comment. Apart from the bit twiddling hack the code looks straightforward enough. Maybe it’s not fair to ask this, but it would be comforting if there were regression tests attached to this change.

In D16998#362732, @mmacy wrote:

> If you care about 32 bit performance perhaps have an ifdef LP64 around the type used.

After testing on an old Pentium 4, turns out the line counting algorithm was slower than the naive implementation because operations on 64 bits long longs were slow. Changing it to use 32 bits long makes it faster but only 1.5 times or so faster.