-
Notifications
You must be signed in to change notification settings - Fork 140
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 #253
Labels
enhancement
New feature or request
Comments
Hey, thanks for flagging the duplication and sketching out how it could be addressed. From what I can tell, this looks reasonable. The user-visible API won’t need to be changed, so as long as the tests keep passing, this should be a reasonable change to make. |
turekt
added a commit
to turekt/nftables
that referenced
this issue
Apr 17, 2024
Refactored obj.go to a more generic approach Added object support for already implemented expressions Added test for limit object Small lint changes Fixes google#253
turekt
added a commit
to turekt/nftables
that referenced
this issue
Apr 17, 2024
Refactored obj.go to a more generic approach Added object support for already implemented expressions Added test for limit object Small lint changes Fixes google#253
turekt
added a commit
to turekt/nftables
that referenced
this issue
Apr 17, 2024
Refactored obj.go to a more generic approach Added object support for already implemented expressions Added test for limit object Small lint changes Fixes google#253
turekt
added a commit
to turekt/nftables
that referenced
this issue
Apr 19, 2024
Refactored obj.go to a more generic approach Added object support for already implemented expressions Added test for limit object Fixes google#253
turekt
added a commit
to turekt/nftables
that referenced
this issue
Jun 25, 2024
Refactored obj.go to a more generic approach Added object support for already implemented expressions Added test for limit object Fixes google#253
turekt
added a commit
to turekt/nftables
that referenced
this issue
Jun 25, 2024
Refactored obj.go to a more generic approach Added object support for already implemented expressions Added test for limit object Fixes google#253
turekt
added a commit
to turekt/nftables
that referenced
this issue
Jun 25, 2024
Refactored obj.go to a more generic approach Added object support for already implemented expressions Added test for limit object Fixes google#253
turekt
added a commit
to turekt/nftables
that referenced
this issue
Jun 25, 2024
Refactored obj.go to a more generic approach Added object support for already implemented expressions Added test for limit object Fixes google#253
turekt
added a commit
to turekt/nftables
that referenced
this issue
Jul 23, 2024
Refactored obj.go to a more generic approach Added object support for already implemented expressions Added test for limit object Fixes google#253
stapelberg
pushed a commit
that referenced
this issue
Jul 24, 2024
Added marshalData func to expressions Prepare parseexprfunc for obj implementation refactor related to #253
turekt
added a commit
to turekt/nftables
that referenced
this issue
Jul 24, 2024
Refactored obj.go to a more generic approach Added object support for already implemented expressions Added test for limit object Fixes google#253
turekt
added a commit
to turekt/nftables
that referenced
this issue
Jul 27, 2024
Refactored obj.go to a more generic approach Added object support for already implemented expressions Added test for limit object Fixes google#253
turekt
added a commit
to turekt/nftables
that referenced
this issue
Jul 27, 2024
Refactored obj.go to a more generic approach Added object support for already implemented expressions Added test for limit object Fixes google#253
turekt
added a commit
to turekt/nftables
that referenced
this issue
Jul 28, 2024
Refactored obj.go to a more generic approach Added object support for already implemented expressions Added test for limit object Fixes google#253
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I am creating an issue as discussed in PR #244.
TL;DR
Current object implementation seems to consist of mostly duplicated code from the
expr
package. This issue tries to present the problem and propose an implementation which reuses theexpr
implementation, removes duplicated code and provides immediate support of all stateful object types supported by nftables.Observations
During implementation of quota objects I noticed that the elements in the object (
Obj
) structs are duplicated. Observe the following counter objectCounterObj
incounter.go
againstCounter
inexpr/counter.go
:Note how expression elements in the struct (Packets and Bytes) are duplicated. Here is their corresponding
unmarshal
ing logic:Marshaling logic is a bit more different since object marshaling creates a complete expression, but the data specific implementation is duplicated:
Furthermore, note the marshaling implementation difference between objects and expressions (
NFTA_EXPR_DATA
vsNFTA_OBJ_DATA
):All implementations are quite similar, if not the same. Essentially, nftables object contains expressions embedded inside of a struct. This is seen in the original nftables implementation (
nft_object_attributes
holdsNFTA_OBJ_DATA
which is a nested nftables expression):Proposal
Current implementation works well, but I believe it can be made more generic by refactoring the
obj.go
code where theObjectAttributes
holds:expr.Any
structThe implementation for fetching table and table family is the same for each object, as seen here:
nftables/counter.go
Lines 44 to 50 in 33ee8df
nftables/quota.go
Lines 74 to 80 in 33ee8df
Since
expr.Any
struct marshaling is implemented underexpr/expr.go
with implementations for each struct in their corresponding files (expr/counter.go
for counter,expr/quota.go
for quotas, etc.), the generic object would perform the same marshaling logic viaobjFromMsg
as it does now for table, name and type, but serialization of
NFTA_OBJ_DATA
would be handed to the corresponding serializer inexpr/expr.go
.With this change, implementation would benefit from immediate support of all object types and there would be no need to implement each object type separately by duplicating already existing code.
The only problem with this refactor is a major change of the current codebase where the serialization of
NFTA_EXPR_DATA
in all expressions supporting objects should be "decoupled" from the currentmarshal
implementation. Observe the following code:The initial call to
netlink.MarshalAttributes
returns the data that we would like to reuse inCounterObj
:In order to perform the previously mentioned refactor idea, all expressions should have the ability to create just the data bytes and return them without the name part.
I'll try to draft what I said previously in Go code.
Some basic changes:
The
unmarshal
ing part:The
marshal
ing part:The
marshal
ing part inexpr
package (seen aso.data().marshal(o.family(), true)
in above code) would need to return only theNFTA_EXPR_DATA
bytes and we could achieve this with an additionaldataOnly
parameter introduced tomarshal
function signature. In case this parameter is set, we would return only theNFTA_EXPR_DATA
bytes, withoutNFTA_EXPR_NAME
attribute, i.e.:Note that the above code was written by heart so mistakes are very much possible. I hope that I didn't miss anything.
Let me know what you think of this approach. If agreed, I can give it a try but I'm not sure when exactly this will be delivered.
The text was updated successfully, but these errors were encountered: