Re: [PATCH bpf-next 2/4] bpftool: add support for subskeletons

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 9, 2022 at 4:10 PM Delyan Kratunov <delyank@xxxxxx> wrote:
>
> Sorry, missed this question originally.
>
> On Fri, 2022-03-04 at 11:29 -0800, Andrii Nakryiko wrote:
> > Split BTF added on top makes it a bit more
> > tolerable (though there is still a bunch of unnecessary complexity and
> > overhead just for that pesky asterisk).
> >
> > Another alternative would be:
> >
> > typeof(char[123]) *my_ptr;
> >
> > This can be done without generating extra BTF. For complex types it's
> > actually even easier to parse, tbh. I initially didn't like it, but
> > now I'm thinking maybe for arrays and func_protos we should do just
> > this? WDYT?
>
> typeof is _technically_ not standard C (I think it'll make it into C23). GCC and
> Clang do both support it but I would guess we'd want the generated userspace
> code to be compatible with as many toolchains and configurations as possible?
> (e.g. people using c99 instead of gnu99)

that ship has sailed, I'm afraid. btf.h and xsk.h (I'm not even
talking about BPF-side headers) both use typeof()

>
> Beyond that, I feel that any complexity saved by the typeof is lost in special-
> casing arrays and function prototypes when the current code is uniform across
> all types.
>
> If you insist, I can go down this path but I'm not super enthusiastic about it
> (and it's harder to read on top of everything).

I can tell you are not :)

I do think that typeof() makes it much easier to follow complicated
cases. Just look at the example below:

static int blah_fn(int x, int y) { return x + y; }

struct S {
        typeof(char[24]) *my_ptr1;
        char (*my_ptr2)[24];

        int (**my_func1)(int, int);
        typeof(int (*)(int, int)) *my_func2;
};


int main() {
        static struct S s;
        char blah[24];
        int (*fptr)(int, int);

        s.my_ptr1 = &blah;
        s.my_ptr2 = &blah;

        s.my_func1 = &fptr;
        s.my_func2 = &fptr;

        return 0;
}


Which one is easier to follow, my_ptr1 or my_ptr2? func pointer is a
bit more hypothetical (hard to come up with realistic BPF program that
would need func pointer type as global variable type), but I still did
it for completeness.


So it's not like I'm dead set against this split BTF approach, I just
do really think that array variable case is better with typeof().

>
> -- Delyan



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux