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.

As @cem pointed out, it's even easier to use strdup().

@imp correctly observed that since the buffer is allocated to fit, then
fully initialized, there's no need to use M_ZERO.

Looks fine to my relatively-untrained eye.

Modulo adding a comment, LGTM.

@avg / @jhb : I think I've addressed everything you were concerned about -- modulo some personal style, which is still conformant with style(9).

Address a few more things @jhb mentioned.

Call only bus_generic_attach(), but not bus_generic_probe(), from the attach
methods. This behaves properly for both pre-loading via loader.conf and loading
via kldload.

At this point, it looks like the only outstanding issue is either adding device_probe_and_attach(), or confirming that it's not necessary. I'll try to do that tomorrow.

Address most of @avg's review comments.

Thanks for finding time for this! I'll address many of your comments and post an updated diff later today.

LGTM.

Remove some stray comments from the manpage.

style(9) changes: Correct formatting of function prototypes and declarations, and re-order variables.

Address some of @cem's review comments.

In D14381#301679, @gallatin wrote:

Well thats embarrassing. Thanks for the fix.

Leading 8-space -> hard-tab. Whoops!

Use the obvious one-liner, which somehow escaped me at the time of the
original diff. Thanks, avg@!

A one-sentence description of what each of the functions does would be good too (i.e. expand ctz => Count Trailing Zeros, etc).

The kernel as a standalone target does not link against libgcc or libcompiler-rt. On platforms (e.g., MIPS and RISCV) that do not have a direct assembly implementation of the relevant builtin functions that zstd references, the compiler converts them into calls to the runtime library intrinsics. Since the kernel doesn't link against the libraries, this results in a failure to link the kernel.

A comment explaining why you're doing all this would be good.

And of course the same comments for _gone_in_dev() as in _gone_in().

I don't understand the G_NOP_PHYSPATH_PASSTHROUGH stuff. Can't you just check for non-NULL or non-empty 'physpath' being passed in?

Heh. I've had a half-done, semi-related change sitting in one of my sandboxes for months.

Is the name correct?

In D13101#272595, @cem wrote:

Switch off of a compression mode enumeration for userspace cores.

In D8244#266597, @rpokala wrote:

@cem mentioned this today. It sounds like this was held up over concerns about the watchdog not getting petted while panicking; is that correct? I ran into the same problem recently, and I solved it by simply adding the following to /etc/ddb.conf:

script kdb.enter.default=call db_watchdog

That stops the watchdog when entering the debugger, which works for both interactive debug sessions and dumping core.

Additionally, r325024 included a change to continue patting the watchdog while dumping core.

If debugger/dump issues were preventing this from landing, I think we're past those now.