User Details
- User Since
- May 28 2014, 2:27 PM (497 w, 4 d)
Today
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.
Yesterday
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?
Sat, Dec 9
I don't understand the change. The epoch protection is already right here. We can safely use CK_STAILQ_FIRST.
Thu, Dec 7
Tue, Dec 5
committed
committed
committed
Mon, Dec 4
Fri, Dec 1
TLDR: if you fine with proposed bump, please approve the revision. Or suggest a larger value to bump to.
Thu, Nov 30
Use better function name in preparation to repair userret() hack.
Wed, Nov 29
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.
Tue, Nov 28
+ one more test - sizes
Fix corner cases covered by updated test.
Mon, Nov 27
Fri, Nov 24
Tue, Nov 21
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?
Mon, Nov 20
Sun, Nov 19
Agreed. If threads aren't created until they are needed adding to GENERIC sound alright. At least for "large" platforms like amd64.
Fri, Nov 17
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: