Sigh, igor.

Last two "the"s.

One more fix from Pau, also use "base system".

• add patch file

This appears to also fix https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261054.

"Once enabled"

Fixes from Pau.

In D33738#764600, @debdrup wrote:

I just noticed one other thing:
The document goes from using one line per sentence to splitting sentences in the middle, which as far as I know causes problems.

Fix formatting, as suggested by debdrup@, and fix a few other nits.

Bunch of updates.

Fix from Pau.

Fixes from emaste@.

In D33750#763251, @pauamma_gundo.com wrote:

IANAL, so I assume that since there's one Linux® early one, removing the (R) everywhere else instead of replacing all with ® is enough of an acknowledgement. Other than that and the 3 nits I spotted, LGTM.

We do have the trademark information for the Handbook itself: https://docs.freebsd.org/en/books/handbook/, click "> trademarks" just below the Copyright, below "FreeBSD Handbook" title. I don't think we need to include the remark in every chapter; I don't see that done anywhere else in the handbook.

Okay, let's fix the "(R)" sillyness first, since it's a mechanical change: https://reviews.freebsd.org/D33750

Regen after committing unrelated parts.

More fixes.

Tweaks.

Axe xsave for now, only call set_fpcontext if we have fpcontext.

Get rid of embedded mcontext_t; instead put FP state into Linux sigcontext_t.
Work in progress, as this still uses old method of handling XSAVE.

I've tried to write a test program, like this:

Style.

Nice, thanks for working on it :-) Wanna team up on updating the Handbook chapter?

Also, for a more general question: why even bother? Does userspace actually access that data, or otherwise make assumptions about it? For arm64 we don't even bother with using linux_specific stack layout, instead we use native FreeBSD mcontext_t and it works fine.

(Also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240768)

Thanks for tracking this down :-) As for change_in_tz() - I hadn't investigated the code around it to figure out if the path can actually change, but it kinda looks like it's trying to avoid making assumptions about it. Still, even if it did change, we would get a different inode/device numbers in stat info, which makes the name check redundant anyway.

Heh, that’s why I didn’t make it a library in the first place I think; naming is hard :-)

(If the patch makes sense I'll also ask pho@ for testing.)

I wonder… what if, instead to linking to a specific mailing list, we just put a “Mailing lists: https://lists.FreeBSD.org”, like we do for forums?

The 4x difference was for 512B-size writes.

It would be nice to have some sort of man page, even a short one to briefly describe the purpose of this utility.

I wonder, should it perhaps also apply to some other SysV IPC resources?