-
Notifications
You must be signed in to change notification settings - Fork 189
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
fix(bpfassets): Fix object file lookup #1419
Conversation
how will be the developer workflow after this? |
With this PR it works from the repository root. |
@dave-tucker can you please add some usage examples in PR description
|
@vimalk78 ah! there was a bug. It turns out golang's |
yupp, for me too.
|
For local development the instructions suggest running: ./_output/bin/linux_amd64/kepler This checks for the bytecode in /var/lib/kepler/bpfassets However, for local development this directory doesn't exist. The fallback was to look in ../../../bpfassets/libbpf/bpf.o Running the recommended command was causing kepler to look in strange locations (i.e /bpfassets) for bytecode. This PR fixes the lookup for local development to use a glob pattern starting at the current directory. This works well for local development, with the added bonus of making it easier to test kepler builds on remote systems since you can also copy the binary and bytecode files together, without having to place the bytecode in a special path. Signed-off-by: Dave Tucker <[email protected]>
For local development the instructions suggest running:
./_output/bin/linux_amd64/kepler
This checks for the bytecode in /var/lib/kepler/bpfassets However, for local development this directory doesn't exist.
The fallback was to look in ../../../bpfassets/libbpf/bpf.o Running the recommended command was causing kepler to look in strange locations (i.e /bpfassets) for bytecode.
This PR fixes the lookup for local development to use a glob pattern starting at the current directory. This works well for local development, with the added bonus of making it easier to test kepler builds on remote systems since you can also copy the binary and bytecode files together, without having to place the bytecode in a special path.