Test for temp record is included into https://reviews.freebsd.org/D53299

In D49459#1213490, @zarychtam_plan-b.pwste.edu.pl wrote:

Are the tests that hard to add, or perhaps can it be proceeded with further without them?

Are the tests that hard to add, or perhaps can it be proceeded with further without them?

Stuck on athn_usb_detach code or executes athn_usb_stop multiple times
I suspect this is due to the msleep on one threat and a wakeup on another, but I am not certain how to isolate the problem.

Abandoning because it's already fixed.

In D47410#1137166, @ziaee wrote:

Hey Damjan. Are you still interested in this? Your latest patch is just removing those blocks. Please squash your commits into one and try remaking the patch. If not, please close this. Thanks for your submission!

Thank you for this fix. Works fine with Netlink.

Current Problem: Running into a recursive mutex based on FreeBSD/OpenBSD mutex styles.

Working to update the athn_usb_init, currently working through the newstate handler.

In D49884#1137462, @imp wrote:

In D49884#1137457, @lwhsu wrote:

I think the current idea is avoiding directly import firmware file into repo. Perhaps we can separate the firmware out. The current approach is using firmware ports/pkg, before having that, we can just put it somewhere and ask people to grab it and put to the required place, for testing.

Or point them at the linux wireless firmware archive repo....

In D49884#1137457, @lwhsu wrote:

I think the current idea is avoiding directly import firmware file into repo. Perhaps we can separate the firmware out. The current approach is using firmware ports/pkg, before having that, we can just put it somewhere and ask people to grab it and put to the required place, for testing.

I think the current idea is avoiding directly import firmware file into repo. Perhaps we can separate the firmware out. The current approach is using firmware ports/pkg, before having that, we can just put it somewhere and ask people to grab it and put to the required place, for testing.

Hey Damjan. Are you still interested in this? Your latest patch is just removing those blocks. Please squash your commits into one and try remaking the patch. If not, please close this. Thanks for your submission!

In D49677#1132641, @tuexen wrote:

If I understand the patch correctly, it contains three components:

• the fix by replacing in_delayed_cksum(m) with in_delayed_cksum_o(m, ipofs) in ng_nat.c.
• adding protection code which logs a warning.
• refactoring the code to remove indentation by using goto send.

It might be useful to separate these three when committing the code.

If I understand the patch correctly, it contains three components:

• the fix by replacing in_delayed_cksum(m) with in_delayed_cksum_o(m, ipofs) in ng_nat.c.
• adding protection code which logs a warning.
• refactoring the code to remove indentation by using goto send.

It might be useful to separate these three when committing the code.

printf() -> log(). Fix type mismatch.

Fix error message.

Fix mismerge.

Thank you for working on this! Can we add tests here?

I vastly under appreciated that folks rely upon the ng_eiface not moving with the struct ifnet. Probably because I've been using them in jails for over a decade and only recently noticed myself.

In D49158#1121374, @zec wrote:

Your obsession with getting rid of the "flawed" if_vmove() is noted, but for the sake of other people who may have a different view, and who have applications relying on this very concept for 20+ years, please do not take that route.

In D49158#1121338, @glebius wrote:

I do not like the plan. The picture drawn shows that a netgraph node in one vnet is connected to a node in a different vnet. This is basically a violation of the idea of vnet. Virtualized stacks should communicate with each other via network protocols, not kernel pointers. The only legal exclusion is epair(4).

I think I'll just accept my understanding is flawed now to save time and withdraw this. Thank you.

I do not like the plan. The picture drawn shows that a netgraph node in one vnet is connected to a node in a different vnet. This is basically a violation of the idea of vnet. Virtualized stacks should communicate with each other via network protocols, not kernel pointers. The only legal exclusion is epair(4). You may create a new netgraph node for your purpose - a node that is present in two vnets, that would be a second legal exclusion to the virtualization rule.

By design, moving an eiface ifnet from one vnet to another always implied that its netgraph node will remain attached in the parent vnet. This is not an omission or a mistake, but a well established mode of operation on which certain applications heavily depend on, and which this patch proposes to change, for reasons not clearly stated.

yay!

Updated to compile and work with the new ifabi changes.

Thanks for the heads up! Looking into it...

hi! I just tried compiling this on -HEAD (to land it today!) and it failed; it looks like you need to go adapt it to the iflib/ifnet changes (ie, that hid struct ifnet behind if_private.h.)