Weird. Sounds like it should be reverted.

Why would you merge this?

Do you think it’s a bad idea to extend the existing WireGuard driver with Netgraph hooks or custom UDP stream processing? (Similar to how mpd handles PPP streams in flexible ways.) — just a side question. Would that be a question better suited for the mailing list?

I think calling it something with "wg" in the name also is like cheating on your homework, poorly. "My dog ate my homework" level of silliness. Like... we all see it there. So just don't do it. Quit trying to call it WireGuard. Make your own VPN protocol, do all sorts of fun things, add this or that random obfuscation idea, whatever. Networking is fun; I don't want to stop you from enjoying yourself. I'm just asking that you don't try to peddle this as some kind of WireGuard thing, because from my perspective, it really is not. And I think this perspective suits us both: by getting rid of "wg" and not trying to pretend it's WireGuard, you get me totally out of your hair and you get to do whatever you want and I don't need to worry about it. And _then_ if you do come across some good ideas you want to upstream or talk to upstream about including in a protocol or whatever else, you can happily send an email to the mailing list, "hey I made a different non-wireguard thing, but I think this would be a cool idea to add. What do you guys think?" And then we can look at it and see. But, anyway, all of that begins by you not trying to pretend this is "wg" anything.

I'm uncomfortable with you calling this "wireguard" in any way shape or form.

"AdvancedSecurity" -- Windows 2000 branding comes to WireGuard!

LGTM.

In D37404#1012430, @gbe wrote:

@des I am not sure how to handle the angle brackets. To remove them is the easy part, but that would change the output of what is currently upstream.

@jason_zx2c4.com would you be fine with the removal?

What ever happened to submitting this upstream in parts, as I described above in my first comment?

In D37404#852492, @lwhsu wrote:

I think this idea is fine, and I would like to upstream things as much as possible, since that currently what in base is mostly the same as upstream.

Is it possible for us to accommodate both Linux and FreeBSD parts in one wg(8) page? Most parts of the wg(8) are still sharable between platforms. I think we have some ways:

1. Mention everything in the manual page, e.g.,

SEE ALSO

On Linux:  wg-quick(8), ip(8), ip-link(8), ip-address(8), ip-route(8).
On FreeBSD: netstat(1), ifconfig(8), route(8)

2. If there are more and more difference, Let's split the manual pages into platform independent and platform dependent parts, i.e.: wg(8), wg-linux(8), wg-freebsd(8),

3. If 2) looks scary or inconvenient to the users (seems so), we can have a simple pre-procressor to process 1) and accept platform as a parameter to generate the final file we want.

I think at this stage, 1) should be sufficient and let's try to avoid going to 2) and 3) in the future.

In D37404#850530, @pauamma wrote:

Would replacing the roff(7) typographic markup with mdoc(7) semantic markup (in a future change if not here) be too much for upstream to take?

In D37404#850550, @kevans wrote:

Frankly, I'm not comfortable with taking -this- much of a diff without looping in upstream in advance -- the SEE ALSO proposal was reasonable, though. Adding Jason in on this.

In D28136#681602, @hselasky wrote:

Some kernel drivers call ifhwioctl() from under a mutex. Just grep for it in sys/

In D28136#681555, @hselasky wrote:

We need to tweak this a little bit. There appears to be some sleepable mutex after non-sleepable mutex issues here.

Seems clean and simple to me. Nice improvement over the last revision. Let's merge this.

Sure, that approach works fine too, and amounts to the same thing you'd arrive at with SRCU or epoch.

Another approach would be to add SX_NOASSERTS (in addition to SX_NOWITNESS), which would skip those KASSERTs and such.

If you look at _sx_xunlock() you see there is an assert that same thread locks and unlocks.

I don't think we want LinuxKPI stuff in core networking code, right?

I just wrote up a workaround of calling WITNESS_DESTROY and INIT manually like the vfs code which would work but was hackish, and then realized....

In D28136#681208, @hselasky wrote:

Ping - any more comments or ideas here?

I had previously sent this to freebsd-net, but I'm told phrabricator is a better place for it. Copy and pasting from: https://lists.freebsd.org/pipermail/freebsd-net/2021-April/058173.html :

In D28136#670107, @hselasky wrote:

Jason, we could possibly use a SX lock too, but I need to check it a bit. SX locks have a WITNESS object when debuggin is enabled and needs to be destroyed.
In your example, you need to point out where to xunlock aswell, because I'm not sure if it is a good idea to destroy locked mutexes.

It looks like the idea here is to increment a reference during ioctl, drop it at the end of an ioctl, and never increment a reference if it decrements to zero. Then, when destroying, you can simply drop the final reference and then sleep-loop until the reference drops to zero before you move on freeing things.