Looks good to me.

In D42845#977215, @tuexen wrote:

Question: can the moving of the sysctl variable be MFCed? Enabling the feature can, of course.

It is user visible change. I think it can NOT be MFCed unless it is treated as debugging purpose only knob.

In D42678#976149, @jhb wrote:

I suspect we need this more broadly. Several places in here can call attach. That said, I wonder if the better fix is that ether_ifattach needs to set a default vnet if one is not already set.
Oddly, both if_alloc and if_attach set if_vnet which seems buggy. if_detach sets the current vnet to if_vnet before doing the meat of the work. I do think this should be managed down in the ifnet layer and not up here in devctl.

Agreed.
Indeed only network devices need this. I had an idea that checks class of device before set vnet0 but that seems to be layer violation, and also CURVNET_SET_QUIET can not be simply wrapped around by if condition.

Look good to me.

Ping @jhb .

FreeBSD does not use GNU assembler in its base system. llvm-as(1) is now in the base system

llvm-as is in ports. It is not in base system.

zlei@:~ % freebsd-version -ku
14.0-RELEASE
14.0-RELEASE
zlei@:~ % which llvm-as
llvm-as: Command not found.

In D42721#974725, @zlei wrote:

Back to the report by @freebsd_igalic.co :

but we don't know what it was renamed from, and this only works for *real* interfaces, not for cloned devices, or epairs.

And by @kevans

Just last week I found this quite a pain as well; once an interface has been renamed, if it's not a pseudo-interface with an obvious group there's no clear way, AFAICT, to determine which driver created it without perusing pciconf output or whatnot and hopefully being able to associate the NICs listed with the new names (easier when there's only one NIC, of course). Kind of a pain when you're working on a remote machine that you're not at all familiar with.

I would summarize as following:

1. For physical interfaces, it is absolutely necessary to get its driver name and driver unit. Also sysctl dev.<name>.<unit> would give us additional useful info.

Interface name of usb ethernet is ue%u , and the MIB is net.ue.<unit>. It is different from that of PCI ethernet interfaces.

# sysctl net.ue.0
net.ue.0.%parent: ure0

Back to the report by @freebsd_igalic.co :

but we don't know what it was renamed from, and this only works for *real* interfaces, not for cloned devices, or epairs.

In D42721#974631, @karels wrote:

There seems to be an unanswered question. Should the driver name be printed

1. With -D only (as now)
2. With -D or -v (so verbose is fully verbose)

Either one should be OK. I would treat -v as an option for debugging purpose.

1. With -v only (I'm not fond of this one)
2. Anytime the driver name is different than the interface name (including the outliers Kristof mentioned)
3. Always (I considered this. and hopefully scripts wouldn't break. but ...)

I'd prefer Always. Just keep it simple. Do not be too smart.

Sorry this is an excessive late response .

For average user EINVAL usually means that their input isn't correct. It is equally misleading as ENOENT. For more experienced user (I speculate) it is known that "file not found" actually means "entity no found".

Generally speaking, a more precise error number is valuable. But I think it is case by case.

Looks good to me.

During boot-up (or shutdown), when eventd/syslogd is not up, some conditional messages are too expensive to send to console by default

Do you have a measure how will this change improve?

Looks good to me.

I tested FreeBSD-11.4-RELEASE-amd64-bootonly.iso which does not have d9ce8a41eac9 ,:

# kldunload kernel
kldunload: can't unload file: Device busy

There is also log kldunload: attempt to unload file that was loaded by the kernel from dmesg.

I was about to commit this I found that prior to d9ce8a41eac9 (kern_linker: Handle module-loading failures in preloaded .ko files) the kernel can not be unloaded.

In D42453#968771, @jhibbits wrote:

There's no "netstack" module in the FreeBSD kernel. I think a DECLARE_MODULE needs added, probably to sys/net/if.c, before this works.

Looks good to me.

In D42402#969272, @crest_freebsd_rlwinm.de wrote:

Is there enough space in the message to help users by giving them a reference to the new interface to express the same configuration and what form of reference would work well for this?

Xref https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273907

Ping @whu .

Address @whu 's comment.

In D42414#968126, @mhorne wrote:

In D42414#968057, @zlei wrote:

@schakrabarti_microsoft.com @andrew

From the review D41728 I guess on x86 there should have hardware coherency.

I might get wrong place but did not find any useful information about "Coherency" or "vmbus_res" or "_CCA" from the public document [1].
So is the "Coherency attribute" is ARM64 specific ?
Then we may want coherent default to true on x86 and false on ARM64.

1. https://github.com/MicrosoftDocs/Virtualization-Documentation

It does not exactly answer the question, but the BUS_DMA_COHERENT flag has no effect on the x86 busdma implementation.

It is definitely the right fix.

A friendly ping before committing this.

From the review D41728 I guess on x86 there should have hardware coherency.

Address @ken 's comments.

In D42402#967566, @ken wrote:

This makes it sound like unmapped I/O and rotating media support will be removed in FreeBSD 15.

From the context, I think you just mean that the separate sysctl variables to control those settings will be removed, not the underlying support. Is that correct?

Looks good to me.

This is a breaking change. 3rd party drivers should take care of it.