For some reason this patch is not working for me, It works fine on macOS. I'll take a closer look later.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 13 2023
Nice catch! Thank you!
Just a few minor suggestions in the tests.
Jul 11 2023
Unfortunately I didn't get world to build
with gcc due to unrelated errors.
Jul 8 2023
In D40730#931752, @fuz wrote:In D40730#931286, @jlduran_gmail.com wrote:This broke builds using GCC 12 (https://cirrus-ci.com/task/6627586759983104). Is this being currently addressed?
I have a workaround for this breakage which I plan to investigate next week. The idea is to switch back to __builtin_ctz when building with gcc, which does not trigger the warning.
Jul 7 2023
This broke builds using GCC 12 (https://cirrus-ci.com/task/6627586759983104). Is this being currently addressed?
Just in case, please see GitHub Pull request #790.
Jul 3 2023
In D38766#929900, @gjb wrote:I'm sorry, I did not see this review. :(
To be fair, I was away for medical reasons around the time of submission, but I am still sorry this went unaddressed for so long.
Closed by 3f21d3e0babacabb9a32e0e9a8ab290025d5577c.
Jun 16 2023
In D38783#883124, @gbe wrote:In D38783#883015, @jlduran_gmail.com wrote:First of all, thank you for taking care of documenting this type of changes!
I believe we almost forgot about DXR, something along the lines that it can be loaded with fib_dxr.ko.
Unfortunately, the best documentation I could find in base is in the code itself (and in the diff before it landed).OK, that's interesting. I just look on a very recent stable/13 and there is the module not present. On a -CURRENT from yesterday it is. When loading the module a DXR algorithm is available for IPv4 in terms of
net.route.algo.inet.algo_list: dpdk_lpm4, bsearch4, radix4_lockless, radix4, dxr}@melifaro can you give us a little bit more insight here?
May 20 2023
In D38490#914771, @bcr wrote:Any updates here? I'd be happy to approve the man page change.
May 5 2023
Apr 25 2023
In D39760#905888, @vmaffione wrote:I can commit this if needed
Apr 22 2023
It is worth noting that the man pages in this directory are not installed by make install.
Apr 13 2023
GitHub branch/internal pull request: https://github.com/jlduran/freebsd-src/pull/26
Apr 10 2023
GitHub branch/internal pull request: https://github.com/jlduran/freebsd-src/pull/25
Apr 6 2023
In D39445#898034, @kp wrote:In D39445#897963, @kp wrote:In D39445#897960, @markj wrote:This is neat. It took me some time to understand what's going on, but certainly this framework is better than atf-sh for writing complex or heavily parameterized tests.
I'm currently trying to write a carp test based on this example, and ... well, I can sort of see it making sense when I need scapy to parse packets (which is what I want to do in the test I'm writing), but there's a lot of magic here, and it's taken me quite a bit of time already just to get the setup going (a vnet jail with one epair interface with carp configured on it), and it still doesn't do things that are trivial in atf-sh (How do I skip the test if carp.ko is not loaded?).
Having more or less finished that test (D39454) I think my view remains that python is great for tests that do things like use scapy to parse packets, but I don't think they'd be suitable for tests such as pfsync:bulk (and indeed the majority of pf tests) where 99% of the test is setup.
There's a fair criticism of the atf-sh tests that there's a lot of boilerplate, but I find it makes the test more obvious about what's going on. That is, I can read the test as if it were a very simple shell script. Nothing is hidden, and it's clear what setup is being created.
I believe that in some cases, complex templates can be created, for example:
outside | +---+---+ fw2 --- fw2 +---+---+ | inside
can be a class named SimplePFSync that you can inherit in your tests. You would need to understand what SimplePFSync does and returns first (as a newcomer), also it will likely reside in some common file somewhere else (as I understand you prefer to see the setup explicitly in the test), but it should allow you to focus on what's being tested. It is a matter of personal preference, of course.
If this is is just a PoC for the discussion in D39420, please ignore. Otherwise, I believe this will need an ObsoleteFiles.inc entry?
The only drawback I can find to python tests is that they run a bit slower (for now [1]), allegedly compensated by reduced development time :-))
Apr 4 2023
Apr 3 2023
- Fix indentation
In D39126#896811, @markj wrote:This is looking ok to me with the nits resolved.
Tangential question: Should we add some atf-sh tests with the test plan, even if simplistic, for this and some of your previous ifconfig(8) improvements? If you think it's worth the trouble, I'll try to submit them.
Mar 28 2023
Cross-builds on GitHub are failing for macOS, as secure_getenv() does not exist. Should I add it to tools/build/cross-build/include/mac/stdlib.h?
Mar 25 2023
Taken from a truss output:
open("/lib/libcap_dns.so.2",O_RDONLY|O_CLOEXEC|O_VERIFY,066000) ERR#2 'No such file or directory' open("/usr/lib/libcap_dns.so.2",O_RDONLY|O_CLOEXEC|O_VERIFY,066000) ERR#2 'No such file or directory' open("/usr/lib/compat/libcap_dns.so.2",O_RDONLY|O_CLOEXEC|O_VERIFY,066000) ERR#2 'No such file or directory' open("/usr/local/lib/libcap_dns.so.2",O_RDONLY|O_CLOEXEC|O_VERIFY,066000) ERR#2 'No such file or directory' open("/usr/local/lib/compat/pkg/libcap_dns.so.2",O_RDONLY|O_CLOEXEC|O_VERIFY,066000) ERR#2 'No such file or directory' open("/usr/local/lib/perl5/5.30/mach/CORE/libcap_dns.so.2",O_RDONLY|O_CLOEXEC|O_VERIFY,066000) ERR#2 'No such file or directory' open("/usr/local/lib/perl5/5.32/mach/CORE/libcap_dns.so.2",O_RDONLY|O_CLOEXEC|O_VERIFY,066000) ERR#2 'No such file or directory' open("/usr/local/llvm11/lib/libcap_dns.so.2",O_RDONLY|O_CLOEXEC|O_VERIFY,066000) ERR#2 'No such file or directory' open("/usr/local/llvm15/lib/libcap_dns.so.2",O_RDONLY|O_CLOEXEC|O_VERIFY,066000) ERR#2 'No such file or directory' open("/lib/casper/libcap_dns.so.2",O_RDONLY|O_CLOEXEC|O_VERIFY,066000) = 3 (0x3)
After this change, it'll match on the first attempt.
Mar 24 2023
- Move the tests to a separate commit
- Drop style(9) changes
Mar 23 2023
In D39233#893290, @cy wrote:In D39233#893286, @jlduran_gmail.com wrote:In D39233#893278, @cy wrote:Jumbo commits are discouraged. Can you break this revision into three, please.
One to fix the error.
Another to fix the regression.
A third to fix style(9) + whitespace changes.
Will do. In that case, I have a commit just to fix style for the entire file (will be submitted after 13.2-RELEASE, as requested).
Typically what I do is create a git branch and do all my commits there. Sometimes I will submit the reviews separately or if it loses context I submit one review, stating that the one review will be commmitted using N commits.
Yes, it’s on https://github.com/jlduran/freebsd-src/commits/ping-fix-20b4130. However, I’d like to clean it up a little. Tomorrow will do. Thank you!
In D39233#893278, @cy wrote:Jumbo commits are discouraged. Can you break this revision into three, please.
One to fix the error.
Another to fix the regression.
A third to fix style(9) + whitespace changes.
This can now be abandoned. Thank you!
Mar 22 2023
Address issues:
- Move the interrupt handler function onsignal() to main.c. When a SIGINT is received, check to avoid PR 4696, although I was not able to reproduce it. I am currently working on adding tests for interrupts and this will become a test. I suspect cap_gethostbyname2 is not bound to the same threading issues as gethostbyname2 (back when the bug was filed)
- Unify F_NUMERIC and F_HOSTNAME constants, given numeric output is the default, use F_HOSTNAME (-n and -H should be mutually exclusive?)
- Reduce diffs between ping.c and ping6.c whenever possible
Mar 21 2023
Mar 20 2023
Mar 17 2023
- Reset seenint and seeninfo counters for SIGINT and SIGINFO respectively, just like ping6.c
- Do not use D38483 as a parent revision
This revision now gets in the middle of a more important one. Let's abandon it... if there is interest, revisit.
Address suggestions:
- Remove SIGINFO guards
- Remove onint()
In D38485#891006, @markj wrote:In D38485#890556, @jlduran_gmail.com wrote:In D38485#888290, @jlduran_gmail.com wrote:In D38485#888217, @markj wrote:In D38485#888216, @jlduran_gmail.com wrote:In D38485#888201, @markj wrote:In D38485#877727, @jlduran_gmail.com wrote:Address suggestions:
In this first iteration, simply duplicate the code from the final statistics section into SIGINFO's.I think this can be committed as-is. Is there a review up to unify them?
I was planning on leaving that unification for last, but let me try to at least unify and test this user-facing part.
Maybe I should put all shared code in sbin/ping/utils.c... I'll work on that. Thank you!Will you update this review with the result? I'll hold off on committing in that case.
Actually, I'll be submitting a separate review, it's a long diff.
I placed the unified code into main.c, as more elements are unified, they'll also be placed in main.c?
I'll wait over the weekend to let these changes soak in, before formally creating the review. But, if you want to take a preliminary look:
https://github.com/jlduran/freebsd-src/tree/ping-interrupts-ping6-unificationThe code has been rebased on GitHub, and the proposal of this diff unified has been submitted as D39126.
Thank you!Do I understand correctly that this review is now obsolete in favour of D39126?
Mar 16 2023
- Address comments
- Set D39125 as the parent revision
Sigh, use the right base for the diff.
In D38485#888290, @jlduran_gmail.com wrote:In D38485#888217, @markj wrote:In D38485#888216, @jlduran_gmail.com wrote:In D38485#888201, @markj wrote:In D38485#877727, @jlduran_gmail.com wrote:Address suggestions:
In this first iteration, simply duplicate the code from the final statistics section into SIGINFO's.I think this can be committed as-is. Is there a review up to unify them?
I was planning on leaving that unification for last, but let me try to at least unify and test this user-facing part.
Maybe I should put all shared code in sbin/ping/utils.c... I'll work on that. Thank you!Will you update this review with the result? I'll hold off on committing in that case.
Actually, I'll be submitting a separate review, it's a long diff.
I placed the unified code into main.c, as more elements are unified, they'll also be placed in main.c?
I'll wait over the weekend to let these changes soak in, before formally creating the review. But, if you want to take a preliminary look:
https://github.com/jlduran/freebsd-src/tree/ping-interrupts-ping6-unification
Mar 15 2023
I was planning on proposing —specifically for GitHub pull requests— to use their own Super-Linter, maybe submitting a mandoc linter as well.
It uses clang-format, however checkstyle9.pl is less aggressive than clang-format (and from a brief test, more accurate!). It also has the advantage that it can be used in almost any development setup. Nice!
Mar 13 2023
In D38469#888919, @markj wrote:In D38469#888306, @jlduran_gmail.com wrote:Try a different approach.
Given this is the base revision for a number of others, some merge conflicts may arise. At any rate,w2 I have a branch with all the other accepted revisions already rebased just in case.
The code inside pr_retip() is only done here for completeness, as it will be completely removed later on.Could you please point me to the branch? I can commit them now.
Mar 11 2023
Try a different approach.
Given this is the base revision for a number of others, some merge conflicts may arise. At any rate,w2 I have a branch with all the other accepted revisions already rebased just in case.
The code inside pr_retip() is only done here for completeness, as it will be completely removed later on.
In D38485#888217, @markj wrote:In D38485#888216, @jlduran_gmail.com wrote:In D38485#888201, @markj wrote:In D38485#877727, @jlduran_gmail.com wrote:Address suggestions:
In this first iteration, simply duplicate the code from the final statistics section into SIGINFO's.I think this can be committed as-is. Is there a review up to unify them?
I was planning on leaving that unification for last, but let me try to at least unify and test this user-facing part.
Maybe I should put all shared code in sbin/ping/utils.c... I'll work on that. Thank you!Will you update this review with the result? I'll hold off on committing in that case.
Actually, I'll be submitting a separate review, it's a long diff.
I placed the unified code into main.c, as more elements are unified, they'll also be placed in main.c?
I'll wait over the weekend to let these changes soak in, before formally creating the review. But, if you want to take a preliminary look:
https://github.com/jlduran/freebsd-src/tree/ping-interrupts-ping6-unification
Mar 10 2023
In D38485#888217, @markj wrote:In D38485#888216, @jlduran_gmail.com wrote:In D38485#888201, @markj wrote:In D38485#877727, @jlduran_gmail.com wrote:Address suggestions:
In this first iteration, simply duplicate the code from the final statistics section into SIGINFO's.I think this can be committed as-is. Is there a review up to unify them?
I was planning on leaving that unification for last, but let me try to at least unify and test this user-facing part.
Maybe I should put all shared code in sbin/ping/utils.c... I'll work on that. Thank you!Will you update this review with the result? I'll hold off on committing in that case.
In D38485#888201, @markj wrote:In D38485#877727, @jlduran_gmail.com wrote:Address suggestions:
In this first iteration, simply duplicate the code from the final statistics section into SIGINFO's.I think this can be committed as-is. Is there a review up to unify them?
Mar 5 2023
Just as a reference, here is OpenBSD's commit:
https://github.com/openbsd/src/commit/0c54afce7b19bf1867acebc6219af5943ce387c3
Mar 3 2023
Amazing!
Mar 1 2023
I like the overall idea, thank you for adding more conf.ds to FreeBSD!
Feb 27 2023
I have also confirmed it is present on 13.2-BETA3.
It is essentially another IPv4 lookup scheme developed by zec@ and luigi@ more info in the 2012 published paper, and the Phabricator review D-29821, designed as an alternative to using ASICs, targeting high-end routers.
I have not been able to test it, maybe olivier@ ?, but I think the idea here is to just mention its existence.
(Intentionally not tagging users/reviewers)
Feb 26 2023
First of all, thank you for taking care of documenting this type of changes!
I believe we almost forgot about DXR, something along the lines that it can be loaded with fib_dxr.ko.
Unfortunately, the best documentation I could find in base is in the code itself (and in the diff before it landed).
Feb 25 2023
In D38771#882639, @imp wrote:In D38771#882624, @jlduran_gmail.com wrote:Should this file be created under .github, given it is specifically for GitHub contributions, so it does not "pollute" the top-level directory?
For now, I think I'm going to keep it at the top level to give it the maximum visibility. I'll keep that in mind, though.
Should this file be created under .github, given it is specifically for GitHub contributions, so it does not "pollute" the top-level directory?
Thank you for clarifying!
Nice!
Here are a few basic suggestions.
Thank you!
Feb 24 2023
Now that the fix is in place, just commit the tests.
I have also tested this revision, and it is passing all my tests.
I also agree that this is the simpler approach, since it essentially reverts hlen to being a signed integer again.
If this revision gets accepted, I'll update mine to just submit the tests.
Feb 23 2023
In D38431#881732, @cy wrote:See https://reviews.freebsd.org/D38744 for a simpler alternative.
Feb 20 2023
In D38469#880472, @melifaro wrote:In D38469#878061, @jlduran_gmail.com wrote:Address suggestions (not sure if this fits the bill).
EDIT: Let me know if adding const to a bunch of required places is preferred.Apologies for the delay, 13.2 release process is ongoing, so the team and myself are mostly working on addressing the arising issues. Hope we'll be able to get to this (and other) ping diffs closed to the end of the week.
Thank you for being so patient!
No problem at all. Take all the time needed. I can imagine how things are at the moment. I have also stalled the submission of other, minor fixes planned until the slush curfew is lifted.
Feb 18 2023
In D37722#879900, @tcberner wrote:In D37722#879899, @jlduran_gmail.com wrote:In D37722#863538, @dan.mcgregor_usask.ca wrote:This is good, but it doesn't match what Linux does. Both systemd and dbus generate 32 character UUID strings, while this creates 36 character ones.
I'd suggest we strip the '-' characters from the machine-id file, and possibly think about ensuring that dbus's idea of the machine-id is the same as the one generated here, or since dbus will use /etc/machine-id if /var/lib/dbus/machine-id doesn't exist, maybe not generating the latter at all.
@tcberner regarding this comment, should we change it to /bin/uuidgen -r | tr -d - > $t, or something similar? or is not really necessary to strip the -s?
Moin moin
I probably misread the documentation that said that modern systemd creates valid UUIDs. But that probably did not mean also it uses the 'dashed' format.
mfg Tobias
In D37722#863538, @dan.mcgregor_usask.ca wrote:This is good, but it doesn't match what Linux does. Both systemd and dbus generate 32 character UUID strings, while this creates 36 character ones.
I'd suggest we strip the '-' characters from the machine-id file, and possibly think about ensuring that dbus's idea of the machine-id is the same as the one generated here, or since dbus will use /etc/machine-id if /var/lib/dbus/machine-id doesn't exist, maybe not generating the latter at all.
Feb 15 2023
Elegant test implementation! I wonder if the Freudians will find it too scatological.
Feb 14 2023
Address suggestions (not sure if this fits the bill).
EDIT: Let me know if adding const to a bunch of required places is preferred.
In D38470#877133, @markj wrote:So isn't there now a mismatch between hlen and cp when handling IPOPT_LSRR and other options? The loop header increments cp once each iteration but doesn't decrement hlen to match.
I'll test locally with a packet containing LSRR options with just a couple of routers + NOP and see the remaining hlen value.