aya: adds support for AF_XDP #1096
Conversation
Contains user-space functionality for doing AF_XDP socket interactions. Much is copy-paste from xdpilone, but with higher-level abstractions put on top. It should be usable at a high level without requiring unsafe code on the library user's side. The more low-level control is still available, for power users who need that level of control (and accept the safety implications). Fixes: aya-rs#507
✅ Deploy Preview for aya-rs-docs ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Hi and thanks for your contribution!
I'm yet to take a look at the code but something in your commit message set off alarm bells.
Much is copy-paste from xdpilone, but with higher-level abstractions put on top.
xdpilone is licensed under the EUPL-1.2 whereas Aya is Apache 2.0 / MIT.
Unfortunately I don't think we can accept this PR as the license terms are incompatible.
I will get clarification on this, but for now adding a -1 so we don't proceed with merging as-is.
|
@dave-tucker Ok, I wasn't aware of the licensing incompatibility issue, but that's on me I guess. I can rip out the xdpilone parts, shouldn't be too much work. |
|
This may get quite hard. I don't know how hard the EUPL-1.2 is, but you may be contaminated by it. And since you mentioned xdpilone, you may not be eligible anymore for any cleanroom implementation. IANAL though. |
|
Ok. I'm sorry for my mistake, it was stupid of me to not check the license. Would be nice to get clarification on whether or not I'm ineligible for a cleanroom implementation in the future, as I would really like this feature to be available in Aya. Or if someone else plans on implementing it in the near future. |
|
I would also love to see this as part of aya. If not possible, a personal fork of aya would be appreciated |
I mean, the actual functionality is provided by the kernel, I haven't looked at xdpilone (nor at the code in this PR yet) but I imagine that it's 99% API and so would be our impl, so unless we rebuild the same API (which would make no sense), I don't think there's much to worry about. There's only so many ways you can use the underlying API (provided by the kernel), and the whole point of this project is to make an API that would fit with the rest of the aya APIs, so presumably very different from xdpilone? |
Contains user-space functionality for doing
AF_XDP socket interactions. Much is copy-paste
from xdpilone, but with higher-level abstractions
put on top.
It should be usable at a high level without requiring unsafe code on the library user's side. The more
low-level control is still available, for power users who need that level of control (and accept the safety implications).
Fixes: #507
This change is