The if_afdata[] array comes from the old BSD times when it was expected that there would be support for many many address families (e.g. IPX, AppleTalk, etc). Right now it has only two entries AF_INET and AF_INET6. It is very very very unlikely it will ever get a third one. It is much more likely that the array will go away and we will have just ifp->if_inet and ifp->if_inet6. Or maybe something more complicated. Anyway, the access to this data is going to change anyway, so there is no point in overdesigning it right now. Any solution for the sake of IfAPI cleanness is acceptable.

Add CMSG testing to the size test.

Got it. Looks like there is also an assumption here that the first address is always the link level address. Maybe we just need to provide KPI if_getlladdr? May I ask to wait for Alexander melifaro@ to reappear before we proceed forward with that?

I don't understand the change. The epoch protection is already right here. We can safely use CK_STAILQ_FIRST.

committed

committed

committed

TLDR: if you fine with proposed bump, please approve the revision. Or suggest a larger value to bump to.

Use better function name in preparation to repair userret() hack.

In D42830#976836, @bz wrote:

Yes, but it worked for almost 40 years and on every other UNIX/Linux does too. [..] The limits put into that file in the last millennium were and are really not adequate anymore in the last 20 years (despite never been enforced anyway).
Also the changes broke the previous syslogd fixes; this is not just wpa.

This won't work on FreeBSD 14. The notions of "send buffer size" and "max datagram size" are now two different things. Before 14, SO_SNDBUF in reality controlled the maximum datagram size. Now it controls send buffer size.

+ one more test - sizes

Fix corner cases covered by updated test.

In D42646#974984, @ngie wrote:

It's interesting because I didn't think this was an optimization worth making, but I don't know the scenarios that Netflix is dealing with where this test suite might not scale in the scenario you're addressing here.

In D42694#974081, @dchagin wrote:

just out of curiosity, why to not to add new kernel interfaces aka
kern_getsockname3(struct thread *td, int fd, struct sockaddr_storage *ss)
and below, into the pr methods?

In D42635#974075, @dchagin wrote:

Linux emu part, I hope you merge that into at least stable/14

We were actually one step away from a working loadable module.

There should be a strong reference model around ifa. In in6_unlink_ifa() and ifa is expected to be linked into both lists, thus unlinked from both and two references removed. Looks like you have find a scenario when on entry in6_unlink_ifa() isn't linked at least into one list. Can you provide please reproduce recipe for the problem?

In D42646#973650, @ngie wrote:

Would you please add a comment to the tops of functions to note what variables are being set in the functions?

In D42664#973599, @tuexen wrote:

In D42664#973596, @glebius wrote:

Agreed. If threads aren't created until they are needed adding to GENERIC sound alright. At least for "large" platforms like amd64.

Are you preferring to delay the adding of the kernel option until an optimization has been added?

Agreed. If threads aren't created until they are needed adding to GENERIC sound alright. At least for "large" platforms like amd64.

I actually planned to make it a loadable module. Given that it creates extra threads that aren't going to be used by default makes its presence questionable.

Address review comments.

Looks like I lost the vote :) 3 people prefer EINVAL to ENOENT. I guess you dislike ENOENT cause it mentions files and directories and there are no files around. Agreed. Let me tell why I hate EINVAL. Cause it seems as a valid reply to any kind of problem. Developers tend to put it everywhere in the code. If a syscall returns me EINVAL, I can't find the returning line just with grep and my eyes. I end with long dtrace session instead. Numbers:

This sweep covers all regressions in ea82362219ee, which are limited to
check for /dev/mdctl. An alternative fix would be to add to Makefiles
something like: