Looks reasonable to my not-very-CAM-savvy eyes.

boot1.efi.8 needs to mention where boot1.efi lives on disk. (/efi/boot/boot${ARCH}.efi, right?)

In D19827#425235, @imp wrote:

I specifically allowed those duplicates when I was originally reviewing this change....

@avg ping? Please take a look at this in the next day or two. If I don't hear from you, I'll go ahead and submit, but I'd prefer to have your review.

Remove the reference to sysctl(3) from the individual descriptions.

As suggested, simplified the descriptions and added a pointer to the manpage.

Yes, BIOS INT call will treat the 4KB device like if it was 512 byte based and hide the fact we are using multiples of 4KB disk access. This was observed by at least Apple's BIOS.

I'm not sure I understand the point of this. No matter what the GEOM is doing, the BIOS INT call interface doesn't support 4KB sectors...?

Thanks for the feedback, @kib; take another look?

Update descriptions based on Kostik's feedback.

Anyway I have no strong opinion about the prefix/naming, What do you prefer? sysctlmib.h/.c/.3/_* ?

Err, yes. Thanks @rgrimes.

Committed as r343583, but forgot to attach this review to the commit message. 🤦‍♂️

Question: why "sysctlmif", as opposed to "sysctlmib"? Since this is about walking the MIB tree?

Since 12 is already out and using 2, shouldn't that be <= 12?

FWIW, LGTM.

Please create links for ext3fs.5 and ext4fs.5; in share/man/man5/Makefile, add these to the list:

MLINKS+= ext2fs.5 ext3fs.5
MLINKS+= ext2fs.5 ext4fs.5

I went ahead and moved the news.xml change as you suggested; I'm including it there for posterity.

Re-order change to news.xml to be in reverse-chronological order.

Actually include the new key in the diff...

LGTM from a purely technical standpoint. (I'm actively avoiding the larger policy discussion around drm(4) and drm2(4).)

Fix a typo in UPDATING: "jdedc_ts" -> "jedec_ts".

Looks good to me.

... the numbers just happened to coincide here.

The summary says PAU06 is the combination of two already-supported chips: RT5372 radio and RT5392 MAC. But nothing in the diff mentions the latter chip.

In D15927#338098, @erj wrote:

In D15927#337633, @pi wrote:

Please expand LOM to 'onboard interfaces (LAN on Motherboard, LOM)', if possible. I'm a 30-years user of ethernet, but I've never heard that abbreviation.

I don't think it's that rare of an abbreviation, but I can add the expansion.

In D14819#311683, @kevans wrote:

Just a note: Anywhere I wrote {kernel} is because I couldn't come up with a better markup. I have no idea what the ideal syntax is for "this is a path with this variable substituted in" rather than "this is a path with this variable name literally in it"

Might want to poke @imp and/or @jhb while all three of you are in the same city. :-)

I think this looks good now. Now you can point someone who actually knows `rc' at it. :-)

In D15465#326493, @cem wrote:

In D15465#326491, @rpokala wrote:

It looks like the GENERIC configs that you're not updating are for ARM, RISC-V, and PPC64. Why are they being excluded?

PPC64 is not excluded. That's powerpc/conf/GENERIC64.

It looks like the GENERIC configs that you're not updating are for ARM, RISC-V, and PPC64. Why are they being excluded?

Oh, heh, I didn't even realize that this wasn't @ian, since he and I talked about this yesterday. :-)

I started but didn't finish reading through the manpage. My comments so far are in-line.

Out of curiosity, why specifically for chown / chgrp?

It would be good if you explained what a hook was, somewhere before the Exported functions section.

In D14790#311049, @cem wrote:

Feel free to spend a bunch of time documenting libkern if you want. It's definitely valuable and shouldn't be too hard. Mostly just tedious. Maybe a thin document that just defines all of the libc-alike aliases and gets linked in a million places would be enough to start.