Address comments from kib mostly.

I'll wait to see what @manu or others in case of kobject_uevent_env() say and then upload the final diff. Interim version coming in a minute.

Abandon in favour of D26598

While I agree on the counter I am not yet sure I entirely want to lose all these messages.
Some are helpful in that they tell us things. If you are on multiple network as most of my devices are it can become a pain otherwise to retroactively debug.
Given none of them are logged by default (nd6_debug = 0 unless -DND6_DEBUG is used at compile time and nd6.h:#define nd6log(x) do { if (V_nd6_debug) log x; } while (/*CONSTCOND*/ 0) ) can we not just do both?

Rework as suggested by adrian.

In D26554#591413, @adrian wrote:

I'm not a huge fan of this cause honestly we should be doing the epoch enter/exit around a batch.

What I was hoping to do was to create a list of frames from calls to rtwn_rx_frame and then push them up to the stack in a second pass under (a) no lock, avoiding the relock, and (b) being done in NET_EPOCH.

Wanna do that or should I?

We'll probably want to add more of these in the future for vnets, so happy we start to lay the grounds.
Will you work on jail/jail.conf to also pick the right set for devfs depending on whether the vnet option is given? If not you should given @jamie a ping6.

In D26537#591051, @kp wrote:

In D26537#590825, @bz wrote:

Did we ever fix this one?

https://www.openbsd.org/errata48.html
005: SECURITY FIX: December 17, 2010 All architectures
Insufficent initialization of the pf rule structure in the ioctl handler may allow userland to modify kernel memory. By default root privileges are needed to add or modify pf rules.

https://ftp.openbsd.org/pub/OpenBSD/patches/4.8/common/005_pf.patch

I believe you did: https://svnweb.freebsd.org/base?view=revision&revision=302117

This landed by accident in head as https://svnweb.freebsd.org/changeset/base/366112 (not sure why the review wasn't automatically closed either).

Arg. Sorry, used the wrong alias and pushed the change into head instead of here. Please do a post-commit review in head then.

I am mostly interested if the names are okay. I did not want to use _IEEE80211_MS() as that might be confused with some time operation MS_TO_xxx. If the names are okay, I'll wrap the lines and upload a new version for actual review.

Did we ever fix this one?

Thanks!

In D26277#584127, @hselasky wrote:

The kernel linker i FreeBSD has a subtle feature, that if multiple symbols with the same name exist, only the first one is resolved, and no warning is given. Can only be found by a LINT compile.

In case this is correct, should I commit the missing cam_sim_free() call on its own?

In D26277#584196, @manu wrote:

In D26277#584194, @bz wrote:

In D26277#584193, @manu wrote:

In D26277#584190, @bz wrote:

In D26277#584185, @bz wrote:

In D26277#584141, @manu wrote:

Note that this commit, once approved, should be synced with ports update to drm-current-kmod and drm-devel-kmod.

I'll do the due-diligens based on the URL you gave me earlier to see what else we have as common code; which of the branches there do I need to check?

Then we can put it all up (either yours or mine) in here for review, cross-check that all still works and get it into FreeBSD in one go, which should make checking in ports for available functionality in base a lot easier. In other words, I'll not push this into head alone if there's other stuff.

Question: given the linux_firmware.c file there has no author or license on it, do I have to assume the files there are indeed as the directory tree suggests gplv2? Because if they are I don't want to go near their contents.

No, if you look at the history it was imported by markj from drm-next, mmacy is the author I think

Cool. Which branches should I all check or is the linuxkpi basically identical?

The firmware part is identical everywhere (even at https://github.com/FreeBSDDesktop/kms-drm)

In D26277#584193, @manu wrote:

In D26277#584190, @bz wrote:

In D26277#584185, @bz wrote:

In D26277#584141, @manu wrote:

Note that this commit, once approved, should be synced with ports update to drm-current-kmod and drm-devel-kmod.

I'll do the due-diligens based on the URL you gave me earlier to see what else we have as common code; which of the branches there do I need to check?

Then we can put it all up (either yours or mine) in here for review, cross-check that all still works and get it into FreeBSD in one go, which should make checking in ports for available functionality in base a lot easier. In other words, I'll not push this into head alone if there's other stuff.

Question: given the linux_firmware.c file there has no author or license on it, do I have to assume the files there are indeed as the directory tree suggests gplv2? Because if they are I don't want to go near their contents.

No, if you look at the history it was imported by markj from drm-next, mmacy is the author I think

In D26277#584185, @bz wrote:

In D26277#584141, @manu wrote:

Note that this commit, once approved, should be synced with ports update to drm-current-kmod and drm-devel-kmod.

I'll do the due-diligens based on the URL you gave me earlier to see what else we have as common code; which of the branches there do I need to check?

Then we can put it all up (either yours or mine) in here for review, cross-check that all still works and get it into FreeBSD in one go, which should make checking in ports for available functionality in base a lot easier. In other words, I'll not push this into head alone if there's other stuff.

In D26277#584141, @manu wrote:

Note that this commit, once approved, should be synced with ports update to drm-current-kmod and drm-devel-kmod.

In D26099#581614, @hrs wrote:

Sorry for the delay. Looks good to me.

Anyone else comments? Otherwise I'll get it in no later than Tuesday.

Any further comments? I'd love to commit this Monday morning UTC.

Any further comments? I'd love to commit this Monday morning UTC.

Any further comments? I'd love to commit this Monday morning UTC.

Apply the changes suggested by @markj and myself.