Re: [PATCH bpf-next] bpf: Add bpf_read_raw_record() helper

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

 



On Thu, Aug 25, 2022 at 10:53 PM Song Liu <song@xxxxxxxxxx> wrote:
>
> On Thu, Aug 25, 2022 at 10:22 PM Namhyung Kim <namhyung@xxxxxxxxxx> wrote:
> >
> > On Thu, Aug 25, 2022 at 7:35 PM Song Liu <songliubraving@xxxxxx> wrote:
> > > Actually, since we are on this, can we make it more generic, and handle
> > > all possible PERF_SAMPLE_* (in enum perf_event_sample_format)? Something
> > > like:
> > >
> > > long bpf_perf_event_read_sample(void *ctx, void *buf, u64 size, u64 flags);
> > >
> > > WDYT Namhyung?
> >
> > Do you mean reading the whole sample data at once?
> > Then it needs to parse the sample data format properly
> > which is non trivial due to a number of variable length
> > fields like callchains and branch stack, etc.
> >
> > Also I'm afraid I might need event configuration info
> > other than sample data like attr.type, attr.config,
> > attr.sample_type and so on.
> >
> > Hmm.. maybe we can add it to the ctx directly like ctx.attr_type?
>
> The user should have access to the perf_event_attr used to
> create the event. This is also available in ctx->event->attr.

Do you mean from BPF?  I'd like to have a generic BPF program
that can handle various filtering according to the command line
arguments.  I'm not sure but it might do something differently
for each event based on the attr settings.

Thanks,
Namhyung



[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