-
Notifications
You must be signed in to change notification settings - Fork 31
devices: drop cilium/ebpf{,link} deps #64
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| //go:build armbe || arm64be || mips || mips64 || mips64p32 || ppc64 || s390 || s390x || sparc || sparc64 | ||
|
|
||
| package devices | ||
|
|
||
| import "encoding/binary" | ||
|
|
||
| // nativeEndian is used as a workaround for cilium/ebpf/asm | ||
| // which does not accept binary.NativeEndian. | ||
| var nativeEndian = binary.BigEndian | ||
|
Comment on lines
+7
to
+9
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is unfortunate; makes our code more brittle (if there would ever be more build-tags added). Would this be something that could be fixed in ebpf? My AI-buddy suggested something like this could work (but haven't verified); func newBPFRegisters(dst, src Register, bo binary.ByteOrder) (bpfRegisters, error) {
var b [2]byte
bo.PutUint16(b[:], 0x0102)
switch b {
case [2]byte{0x02, 0x01}: // little
return bpfRegisters((src << 4) | (dst & 0xf)), nil
case [2]byte{0x01, 0x02}: // big
return bpfRegisters((dst << 4) | (src & 0xf)), nil
default:
return 0, fmt.Errorf("unrecognized ByteOrder %T", bo)
}
}
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In that case, I guess we could do this locally as well if we don't want to depend on our build-tags being complete; var nativeEndian = detectNativeEndian()
func detectNativeEndian() binary.ByteOrder {
var b [2]byte
binary.NativeEndian.PutUint16(b[:], 0x0102)
switch b {
case [2]byte{0x02, 0x01}:
return binary.LittleEndian
case [2]byte{0x01, 0x02}:
return binary.BigEndian
default:
panic("unreachable: invalid native byte order")
}
}or var nativeEndian = detectNativeEndian()
func detectNativeEndian() binary.ByteOrder {
var x uint16 = 0x0102
if *(*byte)(unsafe.Pointer(&x)) == 0x02 {
return binary.LittleEndian
}
return binary.BigEndian
}
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Initially I had a similar code but I prefer to determine that during compile time rather than run time.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also, if a whole new architecture is to be added to Golang, fixing this code is trivial.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But, we can have a runtime test to ensure our endian-ness is correct. Added.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, generally agreed. I wish there was a builtin endian-ness build-tag or something (and, yes, initially I thought; why not use The long list of platforms made me hesitate a bit (easy to miss one!)
Works for me (for now); still would be great if upstream cilium didn't require us to do this 😅
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I tried: cilium/ebpf#1523
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Why? The overhead should be negligible? |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| //go:build 386 || amd64 || amd64p32 || arm || arm64 || loong64 || mipsle || mips64le || mips64p32le || ppc64le || riscv64 || wasm | ||
|
|
||
| package devices | ||
|
|
||
| import "encoding/binary" | ||
|
|
||
| // nativeEndian is used as a workaround for cilium/ebpf/asm | ||
| // which does not accept binary.NativeEndian. | ||
| var nativeEndian = binary.LittleEndian |
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.
Was there anything in our code that would still be worth upstreaming (even if we don't use it?) not sure how generic our changes are.
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.
This code was/is there, just not as a public API.
I guess the only "unique" code we have here is how we use BPF_PROG_REPLACE. Also, it's not too much code.
See also opencontainers/runc#5218 (comment)