be more intentional / specific about 40 vs 20MHz.

Yeah, thinking about it a bunch more this morning, I think the cleanest / correct-est way to do this is to do the "should I transmit ht40 ?" check first, and then pass in a value about the decided transmit width.

IMHO when we already have an interface route, we should fail on trying to add the same route on different interface.
If you want to test the case that was fixed in D47534 you need to add some static route, then configure interface route that will replace this static route, because interface route has higher priority.

I'm puzzled by how your change could work for you.

In D47876#1091689, @des wrote:

In D47876#1091682, @pho wrote:

I too have been thinking about removing the "Missing EOF hole" comment, but stalled because I still am not sure that the output is correct.
Isn't there supposed to be a virtual hole at the end of a file?

Only if there isn't already a hole there.

$ /tmp/lsholes tmpfs24.sh 
Min hole size is 512, file size is 2382.
data #1 @ 0, size=2382)
hole #2 @ 2382, size=0

I've checked that nobody takes the address of the unaligned members.

Something is broken with v3.5.1 - when I try to pull the alpine image from the docker.io registry it fails:

% podman -v
% sudo podman pull --os=linux alpine                               
Resolved "alpine" as an alias (/var/cache/containers/short-name-aliases.conf)
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
Error: copying system image from manifest list: partial pull of blob sha256:da9db072f522755cbeb85be2b3f84059b70571b229512f1571d9217b77e1087f: format not supported on this system

Offered a test kernel to the user in the meantime. @glebius is probably busy (last I spoke with him) and doesn't mind if you commit?

Update the pkg-plist.

Exp-run requested in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283098.

I just tested these commands from PR:

ifconfig tun0 create
ifconfig tun0 10.10.10.10 20.20.20.20
route -n delete -host 20.20.20.20 -interface tun0

with this patch:

--- a/sys/netlink/route/rt.c
+++ b/sys/netlink/route/rt.c
@@ -1010,8 +1010,9 @@ rtnl_handle_delroute(struct nlmsghdr *hdr, struct nlpcb *nlp,
                return (EINVAL);
        }

In D46301#1091706, @franco_opnsense.org wrote:

(attrs.rta_rtflags & RTF_PINNED) ? RTM_F_FORCE : 0

In D47868#1091708, @christos wrote:

In D47868#1091707, @dev_submerge.ch wrote:

I have to admit the centralization through sound.h goes against my intuition - usually I would only include what is needed, where it's actually used. While this change reduces the number of includes, it makes it even harder to see the dependencies and layers in the sound module. But that's just my opinion, I suppose @markj and @emaste may be the better judges in this case.

While I kind of agree, I notice that some of the includes are simply repeated over and over, so IMHO it's better to just have them in one place. After all, we include pcm/sound.h everywhere anyway. Regarding dependencies and layering, I intentionally excluded pcm/sndstat.c-specific includes since they are not needed anywhere else, as well the foo_if.h ones, which I kept/moved to their respective header files.

• Mk/bsd.port.mk Use WRKDIR instead of WRKDIR:H for GIT_CEILING_DIRECTORIES

An alternative proposal is that we strip pcm/sound.h of any unnecessary includes, and instead do what you said: include only what is needed, where it's needed.

In D47868#1091707, @dev_submerge.ch wrote:

I have to admit the centralization through sound.h goes against my intuition - usually I would only include what is needed, where it's actually used. While this change reduces the number of includes, it makes it even harder to see the dependencies and layers in the sound module. But that's just my opinion, I suppose @markj and @emaste may be the better judges in this case.

I have to admit the centralization through sound.h goes against my intuition - usually I would only include what is needed, where it's actually used. While this change reduces the number of includes, it makes it even harder to see the dependencies and layers in the sound module. But that's just my opinion, I suppose @markj and @emaste may be the better judges in this case.

Like this?

I don't like the idea that you can easily remove PINNED route, but it seems it always worked before.
However as I see, route(8) should pass RTF_PINNED flag to netlink via attrs.rta_rtflags. At least we should reduce use of RTM_F_FORCE only for case when RTF_PINNED was sent from userland.

Here's the update from 5.1.1 to 5.3.1.

In D47876#1091682, @pho wrote:

I too have been thinking about removing the "Missing EOF hole" comment, but stalled because I still am not sure that the output is correct.
Isn't there supposed to be a virtual hole at the end of a file?

Use su -m.

I too have been thinking about removing the "Missing EOF hole" comment, but stalled because I still am not sure that the output is correct.
Isn't there supposed to be a virtual hole at the end of a file? See for example https://docs.oracle.com/cd/E86824_01/html/E54765/lseek-2.html

That does not work for me. This is what I get on a pristine install:

In D46653#1091544, @ngie wrote:

Regarding the change proposed on the GitHub PR. I think it's better to merge the existing PR to keep FreeBSD src/contrib/kyua and the github/freebsd/kyua in sync with absolutely the same commit. And I would open a new PR for the change requested with a reference to the previous GitHub discussion/PR. What do you think is the best here from the organizational perspective?

I don't think it would be a good idea to merge the PR as-is. I'm trying to avoid violating POLA as much as humanly possible for 0.14 and taking a look at the output definitely violates POLA. There are enough Linux/MacOS things to deal with -- I'd rather not get more questions with a UX change like has been made on main...

I've been pondering this and it seems pretty broken in the tree and what I have suggest doesn't make sense.

Hi @mat, I once again appreciate your time and reviews. It is my intention to justify the design choices I made and why I believe them to be important. Of course it's your final call to decide how things should be done and I respect that.

• address feedback (put .Fx on this on line)
• bump .Dd

No git command should be run in WRKDIR, ever. If a port does this, it should be fixed.

I've tested this on every supported rtwn NIC i can find. I think it should be fine.

Basic 14.2-RELEASE testing and main testing [so: 15 as stands] and 13.4-RELEASE testing might be appropriate?

The release referenced was fairly quickly replaced. Sometimes this indicates problematical prior releases. Most recent to oldest: