search

Juniper / ebplane

eBPF based dataplane prototypes
Apache License 2.0
23 stars 4 forks source link

Use libbpf provided in the downloaded kernel source code? #24

Open ccontavalli-j opened 5 years ago

ccontavalli-j commented 5 years ago

@maheshmns @anandrao79 @jscherpelz-juniper for opinions.

Right now, the WORKSPACE definition downloads: 1) kernel source code 2) libbpf from github

... but, the kernel source code already includes libbpf. It's in a subdirectory, the github version is just a mirror of the kernel one.

Should we change the build to: 1) Get a kernel source code 2) Use the uapi headers there, and libbpf there, so they are in sync?

Additionally, but mostly orthogonal to this bug: a) Do we need the ability to use one version of UAPI, and a different version of libbpf? I assume libbpf to be backward compatible? We can probably define a libbpf build rule that depends on the kernel download. And if we need to use a different version, we specify a different kernel download? b) We need the ability to prevent the download, and just point to a local (patched, or distro specific) version of the dependency. Will open a separate issue to address this, but this is a need for every dependency, should be solvable with some bzl magic.

maheshmns commented 5 years ago

I think it’s better to change the build to get kernel source code and use uapi headers and libbpf there. IMO, makes it simpler.

a) Do we need the ability to use one version of UAPI, and a different version of libbpf? I assume libbpf to be backward compatible? We can probably define a libbpf build rule that depends on the kernel download. And if we need to use a different version, we specify a different kernel download?

At least for now, I think this ability may not be necessary. Unless we determine we need more than what is provided from the current libbpf version, it should be ok to pick a linux version that is compatible with the current libbpf version.

b) We need the ability to prevent the download, and just point to a local (patched, or distro specific) version of the dependency. Will open a separate issue to address this, but this is a need for every dependency, should be solvable with some bzl magic

Agree

anandrao79 commented 5 years ago

Hi Carlo,

Yes, this is a good idea and I think it simplifies things. We need to probably investigate the sync script in libbpf a bit more and see if it is just copies files or does more than that.

a) Do we need the ability to use one version of UAPI, and a different version of libbpf?

Yes, but may not be needed immediately, I think.

b) We need the ability to prevent the download, and just point to a local (patched, or distro specific) version of the dependency.

Yes, it is good to do this.

Regards, Anand