I have no objection to it, but it is still not totally factual, more than likely it was "intergrated" into FreeBSD Current/Head when it was at 12 and merged back to stable/11 and first appeared in a FreeBSD release at 11.1. I still do not see any added value to the history of mandoc by this change, and it just makes FreeBSD have a local diff to the mandoc from witch it was derived. Speaking of which, shouldn't this be on a vendor branch?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 24 2020
Jul 21 2020
Jul 20 2020
Jul 16 2020
Jul 15 2020
Jul 10 2020
I see a fair amount of white space/formatting only changes in this, it MAY make since to break those out as 0 effort review.
I also have concerns over any performance claims, though I see the old code is probably at least sub optimal in that it often checks for UDP, then for TCP when the volume of traffic should almost always be mostly TCP. Also modern compilers should just "handle this" without rewritting code unless something odd is being done. If you really want to micro optimize I suspect rewriting this as "branchless" code that results in cmovl or other instructions might be interesting. I have heard of 40x code speed improvements using such tenchiques, but that is mostly in tight loops.
Jul 9 2020
I was asked to look at this and see if I could help get the Makefile issues moved forward. I have commented inline.
In D25601#566423, @imp wrote:In D25601#566410, @markj wrote:In D25601#566409, @imp wrote:I don't think this is a good idea....
Setting sysctl values multiple times may be unwise.o
I concur on this point. Not all sysctl are idempotent.
Jul 7 2020
Jul 6 2020
This is a good fix, it is wrong for the kernel to try and guess that something is wrong here. "Highly Probably != For Certain" and having this kind of stuff get in the way when your trying to make something work is very annoying for the end user. Now if we could just get the hard coded interface loopback route creating/removal out of the kernel.
Jul 5 2020
I do not believe we normally document this type of information in the HISTORY section of manual pages. The history sections of these man pages are already rich with information, especially when you add the history included in the Authors section.
Jul 4 2020
Is it possible to do cgn without rfc1918? I think the changes should allow for that configuration.
Jul 2 2020
Though much better than the prior iteration I believe it leaves some detail out.
Jun 24 2020
Jun 23 2020
This has been in process for 15 months and should be evolving in tree rather than in a review at this point, IMHO. If no one objects to it being committed in 7 days I am asking that Richard go ahead and commit it.
So, is FreeBSD getting close to a proper Cubic yet?
Jun 22 2020
In D25401#560437, @tuexen wrote:The in_pcb_setup code is that called independent of L4? Ie for all sockets? Or have i lost my way in the twisty maze of IP layers?
TCP calls it: tcp_usrreq.c:1566. The logic is independent from L4. They are also rewriting INADDR_BROADCAST, which doesn't make sense for TCP, but we are catching this now...
In D25401#560408, @tuexen wrote:In D25401#560404, @rscheff wrote:Should this
- If the destination address is INADDR_ANY,
- use the primary local address.
It took me a few "brain loops" to realize you mean the "local loopback interface address" or is there actually some concept of a "primary local IP address."?
Jun 19 2020
In D25312#559159, @imp wrote:Summary so far:
- there's overwhelming support for this, at least in theory
- the devil is in the details.
... Much sound analysis removed ...
Jun 18 2020
I find this change debatable, and as presented here incomplete as I believe this has effects on some other parts of style(9), nor does it provide a proper sample (it leaves the example unchanged) Lets not RUSH to slam this in the tree!
Jun 10 2020
Jun 9 2020
Jun 5 2020
If you have clients that need to do this type of thing I would recommend they are running behind DSCP and they should use 2 DSCP's to seperate there DCTCP like traffic from there TCP/reno like traffic. Using ECT(1) as a traffic classifier in advance of IETF clear decision may land them in a very hard to resolve possition in the future.
Jun 4 2020
May 22 2020
No, the point was to reduce the amount of change
Just a couple nits, and I can be ignore on my line breaking issues.
May 21 2020
I'll commit this today
Approving as mentor, only a visual code read was done.
May 20 2020
Works for me
In D24596#548776, @emaste wrote:In D24596#547800, @pi wrote:These types of greps on a linux system return an error message for every directory in the directory you ran the grep in
So if we modify grep to not try to read directories and not spew errors, would that be a solution ?
It wouldn't even take much modification, just changing the default to be -d skip.
Or is there some POSIX or similar rule that requires those errors 8-} ?
POSIX allows implementations to do what they want with read() on a directory and grep's behaviour follows from that, so I think it's within the spirit for us to show errors or not, as we see fit.
May 18 2020
In D24596#547795, @kevans wrote:In D24596#547790, @rgrimes wrote:Now that I have had time to go play with this on a "Linux" system, I am afraid I object to this change. Your doing it because you don't like the occasional splat of "foo is a binary file" when you run a grep *, you should see the results when EISDIR is returned. These types of greps on a linux system return an error message for every directory in the directory you ran the grep in, far more noise than your small issue, and for many of us this is gona be a PITA/POLA change. I hadnt thought much about it cause I alias 'grep' 'grep -d skip' and do not see your issue or my issue normally on linux.
I think to rectifier your issue you should probably do the same I have done...
I'm afraid I have no idea what you're talking about here...grep isn't my problem, my problems are:
- The security implications of being able to read(2) a dirfd,
- Consistency with how most modern kernels behave,
2a) the amount of time I waste hunting down application bugs because of that
There was probably a 3, but it's late and a bit worn down from recent discussions.
In D24596#547205, @imp wrote:In D24596#547104, @mateusz_serveraptor.com wrote:Probably grep(1) should be updated after this change. It has -d option to specify which action to to take on processing directories. From manpage:
-d ACTION, --directories=ACTION If an input file is a directory, use ACTION to process it. By default, ACTION is read, which means that directories are read just as if they were ordinary files. If ACTION is skip, directories are silently skipped. If ACTION is recurse, grep reads all files under each directory, recursively; this is equivalent to the -r option.grep doesn't actually read directories for anything useful (and can't for ZFS), so this change is a nop as far as GREP is concerned.
Now that I have had time to go play with this on a "Linux" system, I am afraid I object to this change. Your doing it because you don't like the occasional splat of "foo is a binary file" when you run a grep *, you should see the results when EISDIR is returned. These types of greps on a linux system return an error message for every directory in the directory you ran the grep in, far more noise than your small issue, and for many of us this is gona be a PITA/POLA change. I hadnt thought much about it cause I alias 'grep' 'grep -d skip' and do not see your issue or my issue normally on linux.
May 15 2020
I do not like the undocumented (per summary anyway) KASSERT added for writes.
May 13 2020
In D24021#546333, @neel_neelc.org wrote:In this patch, "me4" is IPv4-only and "me" is dual-stack. It uses kernel opcodes, however.
May 8 2020
May 7 2020
I know there well be flak over using .Tn in a man page fix, can you submit a new diff without the .Tn's?
May 6 2020
I just fixed a couple typos in the summary, looks ok.
May 5 2020
Can we get some more eyes on this please?
May 3 2020
May 2 2020
Apr 29 2020
Apr 28 2020
Thank you for the comment, that helps me, small english nit
That reads much better, cleaned it up a fair bit more than I thought it would.
Adding bz, as it is his XXX-BZ comment being removed about implementing this.
Request for a comment, non blocking.
Apr 23 2020
Thank you, nice additions beyond what I stumbled on in the PR
Apr 22 2020
If you only knew how long I fought with white space issue, Ar and Cm trying to get that to format correct for cpus=. Thank you!
Apr 20 2020
Apr 16 2020
I would like to see some "area of expertise" comments on this change before I can approve it as a mentor.
Apr 15 2020
Apr 14 2020
Apr 12 2020
The more I think about this the more I think we may want to step back and take a bigger picture view of how ipfw2 deals with ipv4 vs ipv6 and the fact that it originally had no ipv6 support, and the grafting on of that feature left some edges that are not very clean and rather than adhoc try to shove this type of stuff in we should take a look at how to possibly clean up those edges. The basic "proto" match is ip, ip4|ipv4, ip6|ipv6. Reading the man page leads me to a missing bit, src and dst are specified as {addr | .... but I see no path to addr6-list or for that mater a clean path to an ipv6 address specifier. I think if one stepped back and tried to write a formal BNF syntax we would uncover some of the issues that are leading to the poor clarity in syntax today. I avoid most of these issues as my firewalls are written in a way that does protocol classification and dispatch very early so once I decide if a packet is ospf/ipv4/ipv6/icmp/icmp6/etc I no longer care about protocol field at all and know I am dealing with v4 or v6 in each section.
Apr 11 2020
How is any of this being implemented in the kernel filter code itself? If your not adding opcodes I do not see how this can work properly, other than they are purely aliases for what is already in place.
I do not see how this makes any difference between the values me, me4 and me6. There still only appears to be one class of opcode, O_IP_{SRC,DST}_ME. Is that the intent?
Apr 10 2020
Apr 9 2020
You don't have to update the reviewed by/accepted by lines in the reviews, just so long as you commit them with proper values.
In commit messages other committers are refered to without the trailing @ sign. Other than that it looks good, I see you figured out the sorting order, but that file could defanitly use a linting
Apr 7 2020
Remove comment
Can you update the summary to be your actual proposed commit message? You may wish to look at prior commits to this file for the normal form: https://svnweb.freebsd.org/base/head/share/misc/committers-src.dot?view-log
Commit message is usually:
Add myself (rsceff) as a src committer