- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 25 2024
Sep 24 2024
Thanks for help with the syntax.
Sep 19 2024
Emphasize the problem solved
Improvements and fixes
In D46688#1064517, @markj wrote:Thank you for writing this. I included some suggestions, but please feel free to replace them with your own.
Sep 18 2024
Rephrase a little. Mention further work.
Sep 17 2024
Sep 16 2024
Adding assertions to the existing mtod() and mtodo() seems to break some of the existing things. For instance, one case was found in pf, where m_len is calculated after the mbuf data manipulations. It could be re-worked to form m_len first, but more cases like this can be found. Another hypothetical case could be some optimization-like when a code is sure that used amount of data is pulled, even if the type of a pointer means a bigger structure.
Rework structure of test result types metadata. Fix tests.
Sep 15 2024
In D46653#1063256, @kp wrote:My preference would be <passed>/<passed + failed> (X broken, Y failed, Z skipped), so the example would become
0/0 passed (0 broken, 0 failed, 222 skipped)
That's my preference, but I do think that any change would be an improvement over the current misleading output.
Sep 14 2024
In my env it decreases run time of those two test cases from ~15 sec down to ~7 sec. It's kind of "while here" change after the https://reviews.freebsd.org/D46655.
Sep 12 2024
In D46655#1063383, @markj wrote:I don't quite understand the implications of the change. Why do these tests care about whether ipfw is loaded? Will their behaviour change depending on that?
Postpone all the calculations until it's time to print the summary
In D46653#1063244, @markj wrote:BTW, in the FreeBSD regression test suite, it's basically impossible to avoid skipping some tests:
- the are tests that get skipped if ipfw.ko is not loaded, and tests which are skipped if ipfw.ko /is/ loaded,
My TODO already has an item to re-think those ipfw on/off tests with the idea to avoid such separation. It seems not to add much value.
It changes only output of kyua test CLI command. Hence, other outputs like junit are kept intact for CI and other use cases. It's meant to improve UX of attended use cases.
Sep 9 2024
Sep 3 2024
Deflate the diff to the functional change only
In D46496#1060114, @kp wrote:I usually prefer having whitespace/comment cleanup work be a separate commit. That makes reviewing things that much easier.
There's no need to separate it out now, but it's something to keep in mind for future commits.
Sep 2 2024
Fix style as reported by checkstyle9.pl
Rebase.
Aug 31 2024
Remove redundant arg shift operation.
In D46453#1059780, @des wrote:In D46453#1059500, @igoro wrote:Yes, the question is left open why the same is not done for addkey.sh.
Not at all. I wrote addkey.sh, I know perfectly well that no shift is needed there. The question is why one was added here and if there's any reason not to remove it.
Aug 30 2024
Looks great to me.
It's turned out not to break the logic of iterating over the arguments, due to the for construct here has implicit in $@ which gets expanded before the loop itself.
Aug 29 2024
Implement des@ suggestion.
Aug 28 2024
Make it portable instead
Aug 27 2024
Aha, indeed. Now I know why I had the issue -- there is a difference between sh in FreeBSD and macOS. The latter one told me this:
> ./checkkey.sh 0x48FE9F99 ./checkkey.sh: line 108: syntax error near unexpected token `;' ./checkkey.sh: line 108: ` ;&'
The POSIX says :
Aug 26 2024
The review and approval was conducted by email.
Aug 25 2024
Aug 21 2024
Aug 20 2024
It follows and aligns with https://reviews.freebsd.org/D46312.
Aug 16 2024
This is another small step of the mtod revision. The reasoning behind the __predict_false() usage is provided here: https://reviews.freebsd.org/D45762#1055287.
Aug 13 2024
Aug 12 2024
I've invested into detailed analysis. tl;dr: It seems nothing needs changing for now on ipsec/if_enc side.
Aug 9 2024
A couple of improvements:
- Fix the ubiquitous language used in this scope, i.e. stick to the inet term. The upcoming test cases will use inet6 and ethernet pfil naming.
- Speed up the test (kind of x5 in my env) with a stricter timeout for the expected ping failure.
A non-functional update:
- Align naming of vnet (un)init functions with the others in the kernel
Aug 7 2024
In D45928#1054365, @kp wrote:I think the man page could benefit from an editing pass by a native speaker, but it's already about 98% as good as it can be.
Covers the points raised.
Aug 6 2024
Non-functional changes:
- Always reset rule.syntax_* fields before the actual parsing
- Use static MALLOC_DEFINE
Aug 2 2024
Add dummymbuf.4 to the build
Added the initial draft of dummymbuf.4 man page. Any advice is welcome to help making it as concise and clear as possible.
Jul 31 2024
It has been tested for IPv4, IPv6, and Ethernet with the respective fixes on pf side and extra tests in the mbuf.sh. It will be easier to publish them for review after the initial IPv4 case (https://reviews.freebsd.org/D45927) and the module itself get merged.
In D45928#1050017, @kp wrote:.... For this small and self-contained is better.
Add IPv6 and Ethernet support with rules dynamic allocation per vnet.
Jul 25 2024
This is not required anymore and the actual examples can be found within main, e.g. https://cgit.freebsd.org/src/commit/?id=4f752a1583dc97d166caae7f844bf42715e99978.
This has been resolved as a separate https://reviews.freebsd.org/D45865 review. The synchronization with the vendor is expected to be continued on GitHub: https://github.com/freebsd/kyua/pull/224.
Jul 20 2024
Yes, it seems GCC has incomplete support for this, while Clang works with both the virtual function declaration and with its override. Kyua is based on a typical OOP polymorphism case #3:
Jul 18 2024
This update covers the points raised so far.
Jul 15 2024
This update brings in the simplest logging to provide some details if it does not work. I believe that it's a must for this module to save time and minimize possible headache of its users. Also, it may add a little help for the testers and reviewers of the patch.
In D45928#1048116, @kp wrote:We're also missing a little more make glue:
The update includes:
- Apply the review suggestions collected so far
- Rework struct op to struct rule to let the interface and its implementation speak the same language
Jul 11 2024
A slight update: "count" related code needed revising due to it was "offset" in the previous life (as of my first internal iterations).
Jul 9 2024
This is a quick prototype with some edges to polish or re-work completely. It would be interesting to hear opinions before the further effort. The context and use case example are outlined here: https://reviews.freebsd.org/D45927.
The context:
- This is a followup of https://reviews.freebsd.org/D45780.
- As long as it's decided to improve if_enc and/or ipsec code to avoid suboptimal mbufS (https://reviews.freebsd.org/D45762), the existing pf test (the if_enc.sh one) is expected not to provide the expected coverage.
- The idea of this additional test is not to be based on (mis)behavior of other modules.
- But it requires a brand new module -- dummymbuf: https://reviews.freebsd.org/D45928
Jul 3 2024
This is a proposal to apply the jail Kyua patch directly to freebsd-src. The idea is to start battle testing and polishing sooner. While respective integration and synchronization with the github/freebsd/kyua project could go ahead with its own pace.
Do you expect it to be improved like it's proposed in the patch? (some cleanup is needed I guess, and the test case does not make sense now)
Or you have another vision in mind?
Jul 2 2024
After the main change landing brain starts thinking outside of the box. We could save the m_len before the m_pullup for the sake of a detailed error report, but it's not felt to be very important. Let me know if it is.
In D45780#1044977, @glebius wrote:P.S. We didn't pullup potential IP options. What happens if packet doesn't belong to a known protocol (TCP/UDP/etc) but has options and also options are allowed, are we going to dereference beyond sizeof(struct ip)?
This update covers a potential race condition in the test case to avoid false negative.