Re: Portability of bpf_tracing.h

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

 



On Mon, 24 May 2021 at 18:48, Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote:
>
> If there are enums/types/fields that we can use to reliably detect the
> platform, then yes, we can have a new set of helpers that would do
> this with CO-RE. Someone will need to investigate how to do that for
> all the platforms we have. It's all about finding something that's
> already in the kernel and can server as a reliably indicator of a
> target architecture.

Can you explain a bit more how this would work? Seems like leg work I could do.

> Well, obviously I'm not a fan of even more magic #defines. But I think
> we can achieve a similar effect with a more "lazy" approach. I.e., if
> user tries to use PT_REGS_xxx macros but doesn't specify the platform
> -- only then it gets compilation errors. There is stuff in
> bpf_tracing.h that doesn't need pt_regs, so we can't just outright do
> #error unconditinally. But we can do something like this:
>
> #else /* !bpf_target_defined */
>
> #define PT_REGS_PARM1(x) _Pragma("GCC error \"blah blah something
> user-facing\"")
>
> ... and so on for all macros
>
> #endif
>
> Thoughts?

That would work for me, but it would change the behaviour for current
users of the header, no? That's why I added the magic define in the
first place.

-- 
Lorenz Bauer  |  Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK

www.cloudflare.com



[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