-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Objects implementation refactor #259
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, it’s very helpful to see the entire change laid out like that. I left a few detail questions.
54b203b
to
b77f1a9
Compare
bf1fedd
to
c6bcfd9
Compare
c6bcfd9
to
533a934
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I think this looks good overall. Would it be possible to move the refactoring of the expr/*.go files into a separate commit? We could probably even submit that independently, as it should be a no-op, yes?
533a934
to
a8e056d
Compare
Alright, PR #265 is now merged, so you can rebase this one. |
a8e056d
to
b5406ff
Compare
717c691
to
eab2afa
Compare
Refactored obj.go to a more generic approach Added object support for already implemented expressions Added test for limit object Fixes google#253
eab2afa
to
955947b
Compare
Hi,
as per our discussion in #253, I have implemented a change for a more generic implementation of nftables objects. In addition to the refactor I have added a test to demonstrate that already implemented expressions are now supported as objects and made a few lint changes. Note that some of the expressions are currently not implemented in the lib (i.e. synproxy, ct_helper, ct_expect, ...). These can now be easily added to the
expr
package to offer support. I'll see to adding them after we agree on this refactor change.Let me know what you think.