[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQJOZNP+=woGk8OjUgT8yApkrZ1mCKOgzD1mdqi91F1AYw@mail.gmail.com>
Date: Thu, 27 Feb 2020 08:22:48 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: David Ahern <dsahern@...nel.org>,
Network Development <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Prashant Bhole <prashantbhole.linux@...il.com>,
Jason Wang <jasowang@...hat.com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Toshiaki Makita <toshiaki.makita1@...il.com>,
Daniel Borkmann <daniel@...earbox.net>,
John Fastabend <john.fastabend@...il.com>,
Alexei Starovoitov <ast@...nel.org>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
Andrii Nakryiko <andriin@...com>,
David Ahern <dsahern@...il.com>
Subject: Re: [PATCH RFC v4 bpf-next 00/11] Add support for XDP in egress path
On Thu, Feb 27, 2020 at 3:55 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> However, my issue with this encoding is that it is write-only: You can't
> inspect a BPF program already loaded into the kernel and tell which type
> it is. So my proposal would be to make it explicit: Expose the
> expected_attach_type as a new field in bpf_prog_info so userspace can
> query it, and clearly document it as, essentially, a program subtype
> that can significantly affect how a program is treated by the kernel.
You had the same request for "freplace" target prog.
My answer to both is still the same:
Please take a look at drgn and the script that Andrey posted.
All this information is trivial to extract from the kernel
without introducing new uapi.
Powered by blists - more mailing lists