netdev - Re: status of llvm BTF support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <faf5f17c-76d7-ee2d-c702-90aa3457744d@solarflare.com>
Date:   Tue, 18 Dec 2018 16:18:50 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Yonghong Song <yhs@...com>, netdev <netdev@...r.kernel.org>
CC:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Brendan Gregg <brendan.d.gregg@...il.com>,
        "Kernel Team" <Kernel-team@...com>
Subject: Re: status of llvm BTF support

On 17/12/18 22:45, Yonghong Song wrote:
> Hi,
>
> As many of you already knew, latest bpf-next/net-next
> kernel added supports for func_info and line_info.
Is there a proper spec yet, against which other implementations can
 be developed?  Or do folks still have to RTFS and reverse-engineer
 the semantics if they want to support this in tools other than
 LLVM and pahole?
Because IMHO writing a spec should be a higher priority than
 anything else in BTF development; and every patch series that
 changes the format should come with a patch to update the spec.
We're developing a format here, and acting like we don't need to
 do things properly because we 'own' both ends — which is not
 conducive to building an open ecosystem around it.

-Ed