LGTM!

The first hunk is fine and should go in on its own. Again, I'd prefer a vague "prefer top-level default" / don't overdo it, folks, but whatever. It's ok.

Rene reported build success on CURRENT-amd64 as well. Small update, LGTM.

In D25409#564350, @rajesh1.kumar_amd.com wrote:

Thanks @cem for taking time to review the code.

Can this device also be used to offload generic DMA copies? Just curious.

• Drop copyright/license header
• static string

In D25493#564116, @kib wrote:

In D25493#563935, @jhb wrote:

I believe this is correct. I think you only put things in Symbol.map if you want them public for when you link new binaries. We use __sym_compat without any corresponding Symbol.map entries for other compat shims in libc (e.g. fts* symbols in lib/libc/gen/Symbol.map are only the latest FBSD1.5 version and don't include the legacy versions for FBSD1.0 and FBSD1.1.)

You can check readelf -Ds output to verify that there are symbols with name@OPENSSL_1_1_0 version but not name@@OPENSSL_1_1_0. @@ denotes default version used by static linker to record version into the consumer. If there is no '@@' definition, ld(1) refuses to link with the symbol if reference does not specify wanted version.

All memory is freed at program exit.

• Don't print only sizeof(void*) bytes of the warning.

In D25493#563769, @gordon wrote:

Let's go that direction.

Don't abort/kill, just warn once and NULL stub per consensus.

In D25493#563646, @gordon wrote:

It's probably somewhat unfair, but I wrote an SSL scanner a while ago that uses this behavior:
https://github.com/tetlowgm/sslscan

If you know of an example of some software that explicitly invokes every version it knows about (and tries SSLv3 before a TLS version), I've love to see an example.

Just style/typo nits. Functionally, it looks good.

We could provide dummy implementations of these symbols, rather than enabling SSLv3 code in 2020 in our unreleased development version of FreeBSD.

I’m not keen on the short format but I prefer it to “off.”

I’m not keen on the struct <-> array coercion

Some general comments: Usually, you would just put this in sys/dev/ptdma (and sys/modules/ptdma) rather than adding a directory level.

Sure, and sometimes that's fine.

Because you cannot get stable branches ABI-stable if head is not.

Er, why? CURRENT is not ABI stable and SSLv3 is very broken. Applications that want to use a broken cipher can get that from ports.

Builds on 13-current

Thanks! I haven't test-built it yet but can start that.

In D25168#561683, @delphij wrote:

Were you able to find out why GPT partitions are not showing up in the /dev/diskid directory (e.g. /dev/diskid/DISK-BHYVE-2613-8EFD-BAF4p2), or are you not seeing similar behavior (since it might be specific to my usage, details in Message-ID: <cb21f4a0-f9d4-db5d-287a-0cb29c023b75@delphij.net>)?

Thanks!

Seems broadly reasonable to me. I'm not super familiar with the domains logic myself but nothing looks wrong.

No interest in ipsec.

LGTM to me, other than the one question. Approved by: csprng(cem) for the random(4) change.

Oh ffs I'm missing vmm_instruction_emul.h

Nope, even without -DMAKE_JUST_WORLDS it fails to find the new header:

Ah, I was doing tinderbox with -DMAKE_JUST_WORLDS, which I guess skips toolchain bootstrap?

Add CPU, VM_MAP_ENTRY FOREACH; SMR_POINTER

Drop miscfs/msdosfs and add nfs{client,server} to top-level include-ordering rule.

(This is definitely not a complete style(9) .clang-format; the working goal is "less wrong than it was before.")

vm/vm.h must come before vm/pmap.h (and likely all other vm/ headers).

Reorder EXTRAS, FORMAT

Need to figure out a way to get the userspace build to observe the new kernel headers. The <machine/foo> symlink headers aren't pointing at the ones in SRCTOP. I guess I could put __FreeBSD_version conditional dummy prototypes in a userspace header and bump that?

In D24856#560905, @jhb wrote:

*shrug* Given the function already defines variables in scope I'm not sure it really matters to pull it out to the top-level (esp in light of the recent style(9) change Warner is working on).

In D24835#560808, @emaste wrote:

Seems reasonable to me, although I'd also argue that ports ought not set MK_KERNEL_SYMBOLS=no.

Diff looks good to me, thanks. I would suggest not using "emancipation" in the commit subject.

LGTM. A few minor style nits.

Please upload diffs with full context — either using the arcanist tool, or with diff -U999999 (The 9s are just a stand-in for infinity).

Minor update: In the seemingly impossible case where inst_length is zero, don't
leave trash in the vie->num_valid field.