In D20324#443703, @trasz wrote:

I'll elaborate more soon, but basically, this is in the context of https://reviews.freebsd.org/D20477. In short: this is less about using it "when you need a tree", and more about having a tree that you can easily transfer between domains, in this case between the kernel and userspace.

So like, what's the motivation of this change? What are the goals? How was this design chosen? There's 6000 lines of diff present as a fait accompli without any kind of socialization on arch@ or anywhere else. Code is great, but the high level stuff is missing.

The concept is cool but it's impossible to closely review 2000 lines of novel content. On the plus side, half of that is manual page and 1/4 is test cases, so that increases confidence somewhat. Still 500 lines of dense header macros with approximately zero comments (just API specification).

Adjust test to pass bytes, rather than block count.

Rebase onto SVN head

• keystream API takes blocks, not bytes still
• Drop uint128_add64 API tests, which does not exist

In D20529#443815, @vangyzen wrote:

In my opinion, no. To my knowledge, I'm the only person to report this, and I only hit it by running OneFS under bhyve, which uses a larger MAXPHYS.

In D20529#443683, @vangyzen wrote:

Fix it in bhyve instead

In D20529#443608, @bryanv wrote:

What is the panic message?

Restore previous PAGE_SIZE lock yielding behavior.

In D20324#443471, @markj wrote:

I think I understand this a bit better than I did yesterday. The idea is that you allocate your array of objects, and initialize the ARB with the array size, so there's an upper limit on the number of entries in the tree.

LGTM.

In D20324#443241, @markj wrote:

I'm interested in hearing more about the motivation too.

In D20458#443358, @avg wrote:

I would like to commit this change as is now. And then change printf to KASSERT in a week rather than in a month.
Hope that no one would object.

What is the benefit of this new data structure over existing data structures? Do you have empirical results?

In D20508#443091, @jhb wrote:

I find that less readable to add a cast for one of the 4 calls to this function in an expression. This route seems to avoid the need to do similar hacks when decoding other multi-byte values in the future as well.

@bryanv , do you have any remaining concerns with this one? Thanks!

@bryanv, do you have any remaining concerns about this one or could it go in?

I'd cast the left shift instead (leaving the return type matching the type and range of the decoded value), but don't feel strongly about it. This works.

• Drop unneeded headers

• Only allow first virtio_random device to attach

In D20419#442441, @bryanv wrote:

Other drivers following the callout pattern seem to be: bcm2835_rng.c, octeon_rnd.c, hifn7751.c, glxsb.c, tpm20.c although perhaps there is a desired functional difference that I am not aware of.

LGTM!

In D20317#441987, @sam_samgwydir.com wrote:

I added (offset != 0) to the predicate to ignore the final len=0, offset=0 write.

• Fix linking errors introduced inadvertently in r338324
• Correct MD HWRNG drivers in files.* to specify !random_loadable

Is it worth a ratelimit or do none of these show up often in practice? panic is inherently ratelimiting 😁

Consensus seems to be empty (blank) lines for functions with no locals should
be fully optional. Update the text to match.

If there is a cheap way to do it, it might be nice to stop counting at the first (latest) SVN revision. That way git starts over with lower "revision" numbers once an actual switch is made. It's also a shorter walk through git's object graph.

• Handle short reads.

Hey Bryan,

In D20448#441414, @rgrimes wrote:

I would even be fine with "If the function has no local variables",

• Use atomic_thread_fence_rel instead of wmb
• Fix lock leak

In D20419#441239, @bryanv wrote:

It has been a long while since I wrote this driver but the callout pattern was certainly cribbed from another driver in the tree. Has this API changed over the years?

• Document in module.9

• Drop modevent handler changes.

In D19298#440806, @ngie wrote:

1. This broke the build with gcc:

• Extract child_pnp_info routine to virtio.c using generic ivar routines.
• Add missing IVAR accessors to virtio_mmio(4).

In D20406#440587, @markj wrote:

Looks ok to me, but I don't understand the tradeoffs involved in sharing the pnpinfo format among multiple bus types. Is it theoretically possible for there to be a collision, e.g., where two different drivers, one for mmio and one for pci, match on the same string?

Rework comment wording describing the change.

Thanks!