On Fri, Jul 26, 2024 at 4:45 PM Michael Agun <danielagun@xxxxxxxxxxxxx> wrote: > > CC Dave > > Thank you. > > Due to Microsoft policies we avoid reading code with strong licensing (like GPL 2.0). Linux UAPI headers are licensed as `GPL-2.0 WITH Linux-syscall-note`, and see [0]. Will cite it in full below. Doesn't this mean that it's fine to read UAPI definitions? SPDX-Exception-Identifier: Linux-syscall-note SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+, LGPL-2.1, LGPL-2.1+, GPL-2.0-only, GPL-2.0-or-later Usage-Guide: This exception is used together with one of the above SPDX-Licenses to mark user space API (uapi) header files so they can be included into non GPL compliant user space application code. To use this exception add it with the keyword WITH to one of the identifiers in the SPDX-Licenses tag: SPDX-License-Identifier: <SPDX-License> WITH Linux-syscall-note License-Text: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. Linus Torvalds [0] https://github.com/torvalds/linux/blob/master/LICENSES/exceptions/Linux-syscall-note > > Is there some other documentation of the flags, or could you explain them in words? > Or is that the complete flags description (which is in other documentation) and I am misunderstanding the code below? > > https://github.com/cilium/cilium/blob/3fa44b59eef792e28f70b1fd23e3e17e426909f5/bpf/lib/dbg.h#L229 > > It looks to me here like the capture length is being OR'd into the flags. > > Any insights would be appreciated. > > Thanks, > Michael > > ________________________________________ > From: Yonghong Song <yonghong.song@xxxxxxxxx> > Sent: Friday, July 26, 2024 9:58 AM > To: Michael Agun <danielagun@xxxxxxxxxxxxx>; bpf@xxxxxxxxxxxxxxx <bpf@xxxxxxxxxxxxxxx>; bpf@xxxxxxxx <bpf@xxxxxxxx> > Subject: [EXTERNAL] Re: perf_event_output payload capture flags? > > [You don't often get email from yonghong.song@xxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > On 7/25/24 6:42 PM, Michael Agun wrote: > > Are the perf_event_output flags (and what the event blob looks like) documented? Especially for the program type specific perf_event_output functions. > > The documentation is in uapi/linux/bpf.h header. > > https://github.com/torvalds/linux/blob/master/include/uapi/linux/bpf.h#L2353-L2397 > > * The *flags* are used to indicate the index in *map* for which > * the value must be put, masked with **BPF_F_INDEX_MASK**. > * Alternatively, *flags* can be set to **BPF_F_CURRENT_CPU** > * to indicate that the index of the current CPU core should be > * used. > > > > > I've seen notes in (cilium) code passing payload lengths in the flags, and am specifically interested in how the event blob is constructed for perf events with payload capture. > > Could you share more details about 'passing payload lengths in the flags'? > AFAIK, networking bpf_perf_event_output() actually utilizes bpf_event_output_data(), > in which 'flags' semantics has the same meaning as the above. > > > > > > > Thanks, > > Michael >
