David Vernet <void@xxxxxxxxxxxxx> wrote: > On Sat, Mar 11, 2023 at 09:00:19PM +0000, Dave Thaler wrote: > > David Vernet <void@xxxxxxxxxxxxx> wrote: > > [...] > > > > +BPF_CALL 0x8 0x0 call helper function imm see `Helper functions`_ > > > > +BPF_CALL 0x8 0x1 call PC += offset see `eBPF functions`_ > > > > +BPF_CALL 0x8 0x2 call runtime function imm see `Runtime > functions`_ > > > > > > The names "Helper functions", "eBPF functions", and "Runtime functions" > > > feel, for lack of a better term, insufficiently distinct. I realize > > > that it's very tricky to get the naming right here given that some > > > of these terms (helpers + runtime functions) are conceptually the > > > same thing, but as a reader with no background I expect I'd be > > > confused by what the distinctions are as they all kind of sound like the > same thing. What do you think of this as an alternative: > > > > > > 1. Standard helper functions > > > 2. BPF-local functions > > > 3. Platform-specific helper functions > > > > I like where you're going with this. However, the fact is that some > > of the existing Helper functions are actually very platform-specific > > and won't apply to other platforms. So retroactively labeling all of > > them "standard" is somewhat problematic in my view. > > That makes sense. For what it's worth, I was envisioning us specifying both > the helper number (and likely the semantics of those helpers) in the standard, > and just skipping over any which are Linux-specific. Outside the scope of this patch per set, but... FYI, in ebpf-for-windows, we do not currently have a goal to use the same integer numbers as Linux has, only the same prototypes. If there is a strong technical reason to do so, it can be considered, but right now I don't see any need to standardize the actual integer values. We claim BPF program source code compatibility, not byte code compatibility at present. But if the standardization effort does see a need to standardize integer values, we will accommodate. > That's of course assuming we do decide to include functions in the standard, > which to my understanding is not yet finalized. Platform-agnostic helper functions are on the proposed list of things to standardize and for ebpf-for-windows, we do want to standardize a bunch of them that are now common between Linux and Windows and in my view make sense for other platforms too. > Regardless, I'll certainly defer to your expertise on when it's appropriate to > use the word "standard", and I could see why it would be problematic to do > so here. > > > I do like the idea of using "<some adjective> helper functions" for > > both 1 and 3 though. Since we might not choose to standardize all the > > existing type 1 functions, maybe "Platform-agnostic helper functions" > > is synonymous and pairs nicely With "Platform-specific helper > > functions" as a term. And then we could just have a note in the > > linux-notes.rst saying Linux has some platform-specific helper functions that > for historical reasons are used with the platform-agnostic helper function > Instruction. > > That's a reasonable option as well. The only thing that gives me pause is that, > as you know, the plan of record for now in Linux is to have all new BPF -> > main kernel functions added as kfuncs. That includes features which are > "platform agnostic", such as BPF iterators. I know you've previously raised the > idea of having the traditional helpers be used as standard / platform-agnostic > helpers in BPF office hours, so this isn't out of the blue. It seems that the time > has come to discuss it more concretely. [...] Yes, my view which I have expressed in the office hours meetings, is that Linux can do so. But when the time comes to standardize something cross-platform (platform-agnostic), then it gets an integer out of the platform-agnostic space. That means at that point it's not a kfunc, but a classic helper function. But they can start as kfuncs in Linux and do that once standardization is done, potentially having an integer in both numbering spaces if a breaking change is undesired. Other platforms, like Windows, can do the same thing with their platform-specific helper function if one later becomes a platform-agnostic standard. I don't think this affects this patchset right now though, but may affect future ones. -Dave
