In D56512#1294510, @mhorne wrote:

Based on the original submission it is not a typo (D48877). It took one year for the merge to happen. I suggest just to leave it as is.

Based on the original submission it is not a typo (D48877). It took one year for the merge to happen. I suggest just to leave it as is.

LGTM

Rebase the patch.
Don't add operator.7 in MLINKS, since this man page already exists.

Thanks for doing this, and sorry again for the backtracking.

Use recommended wording for non-standard options.

In D56090#1289449, @ziaee wrote:

Sorry to backtrack here (and to let this slip for a while), but I did a deeper dive in preparation for merging this. Looking at our utilities that are specified in POSIX.1-2024:

xargs:
options are non-standard FreeBSD extensions which may not be available on other operating systems.

ls:
are non-standard extensions.

what:
The -q option is a non-standard FreeBSD extension which may not be available on other operating systems.

cut:
The -w flag is an extension to the specification.

pax:
operations are extensions to the POSIX standard.

date:
With the exception of the -u option, all options are extensions to the standard.

patch:
The flags [-BCEFfstVvxz] and [--posix] are extensions to that specification.

env:
options are non-standard extensions supported by FreeBSD, but which may not be available on other operating systems.

find:
are extensions to IEEE Std 1003.1-2001 (“POSIX.1”).

Looking at GNU coreutils (which doesn't provide STANDARDS or COMPATIBILITY sections), they also have both long-options and -v.

The extended documentation for the mdoc language suggests we use are extensions to that specification..

https://mandoc.bsd.lv/mdoc/style/standards.html

Sorry to backtrack here (and to let this slip for a while), but I did a deeper dive in preparation for merging this. Looking at our utilities that are specified in POSIX.1-2024:

xargs:
options are non-standard FreeBSD extensions which may not be available on other operating systems.

In D56112#1283665, @raghav.original_gmail.com wrote:

Thank you Maxim for the review

I will run this through a spell checker.

• Did you write the manpage from scratch or were any parts of it taken from elsewhere, e.g., from NetBSD? If the latter is true, the license

section should reflect it. I am asking because I see that it least some wording matches NetBSD closely.

Some portions of the wordings were taken from NetBSD where behavior seemed similar. How exactly should I reflect this in the license section.

If you borrow a substantial* amount of changes from NetBSD I'd the following:

Thank you both so much!

Take mhorne's suggestion.

sorry i forgot about this! i think this is fine, but id appreciate if a more senior colleague would also look at it.

This should be not a note, but a proper explanation. Besides talking about that, it might be useful to explain how to get the stable results.

Hi @kib,
I read your comments from kern_membarrier.c
Please can you correct me if I'm wrong "The function returns a mask of the CPUs where the given pmap is active(Here a CPU is active for a pmap if its using address space represented by that pmap). CPUs that switch context during the call might be missed, so the caller must ensure synchronization or otherwise the result could be invalid immediately after the call." I'll add this in a separate NOTE section

In D56143#1284104, @kib wrote:

Also it probably worth explaining what 'active' means.

Also it probably worth explaining what 'active' means.

The result of the call is invalid the moment the function returns. If this one-line manual page ever makes sense, it must describe how to use the result safely.

Thank you Maxim for the review

Hi Raghav,

Move non-POSIX options block in the STANDARDS section.

In D56090#1282965, @ziaee wrote:

The COMPATIBILITY section is a GNU-ism.

Merged, thanks Artem! I trimmed the commit message title, some git tooling expects it to be under 51 characters, so try and shoot for that when possible.

Thanks for the patch! The mdoc(7) manual explains that it's important to use standardized sections wherever possible to reinforce the idea that people can jump directly to the relevant section. The COMPATIBILITY section is a GNU-ism. Please put this in the STANDARDS section. Other than that, looks good to me!

Looks good to me. Thank you.

Correct grammar.

Fix a typo: 'signle' -> 'single'.

Can we have this for 15.1, as a little treat?

• Refer readers to malloc(9) for info about malloc types. malloc(9) documents malloc types already. Let's not duplicate documentation.

LGTM, provided the comment is addressed :-)

Could somebody please review this? Or maybe tag appropriate people?