Robin Gögge

Hi, I am thinking about making a GSoC proposal for this issue and I wanted to join the conversation here so that I am able to make my proposal as...

> I don't think it's realistic to completely replace bpftool by a cilium/ebpf implementation in that time frame Thanks for bringing this up @pchaigno, I am currently a bit "overwhelmed"...

Currently I have been kinda building my proposal on the Features struct idea, but I see how this is difficult if individual probes should happen on demand and we don't...

I am still sort of struggling with good and clear use-cases to mention in a proposal for GSoC. As stated above I started out with a `Feature struct` and this...

Hey @lmb, I actually used that piece of code and based my GSoC proposal partly on it, suggesting "similar" functions to test features like you are suggesting here: ``` func...

Hey @lmb, I want to discuss your suggestions of having the features API in a separate `pkg features`. I currently started a first basic implementation of probing for map types...

Ok. Then I'll try and start moving those to internal. :+1:

I have a couple of open questions/status updates I'd like to share: * Currently I am working on implementing the probes for the last missing MapTypes: `SkStorage, StructOpts, RingBuf, InodeStorage,...

Hi, > Does the BTF have to be generated on the fly or could pre-create it and include the raw bytes? For now I actually got away with not creating...

Besides the open points (error interface, "configurable" flags") discussed in the messages above, what is needed to turn my draft PR into a "non-draft" PR which we eventually can merge?