All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wangnan (F)" <wangnan0@huawei.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: <paulus@samba.org>, <a.p.zijlstra@chello.nl>, <mingo@redhat.com>,
	<acme@kernel.org>, <namhyung@kernel.org>, <jolsa@kernel.org>,
	<dsahern@gmail.com>, <daniel@iogearbox.net>,
	<brendan.d.gregg@gmail.com>, <masami.hiramatsu.pt@hitachi.com>,
	<lizefan@huawei.com>, <linux-kernel@vger.kernel.org>,
	<pi3orama@163.com>, xiakaixu 00238161 <xiakaixu@huawei.com>
Subject: Re: [RFC PATCH v4 10/29] bpf tools: Collect map definitions from 'maps' section
Date: Fri, 29 May 2015 11:59:18 +0800	[thread overview]
Message-ID: <5567E416.2080206@huawei.com> (raw)
In-Reply-To: <20150529033518.GA21616@Alexeis-MacBook-Pro.local>



On 2015/5/29 11:35, Alexei Starovoitov wrote:
> On Thu, May 28, 2015 at 03:14:44PM +0800, Wangnan (F) wrote:
>>
>> On 2015/5/28 14:09, Alexei Starovoitov wrote:
>>> On Thu, May 28, 2015 at 11:09:50AM +0800, Wangnan (F) wrote:
>>>> However this breaks a law in current design that opening phase doesn't
>>>> talk to kernel with sys_bpf() at all. All related staff is done in loading
>>>> phase. This principle ensures that in every systems, no matter it support
>>>> sys_bpf() or not, can read eBPF object without failure.
>>> I see, so you want 'parse elf' and 'create maps + load programs'
>>> to be separate phases?
>>> Fair enough. Then please add a call to release the information
>>> collected from elf after program loading is done.
>>> relocations and other things are not needed at that point.
>> What about appending a flag into bpf_object__load() to let it know
>> whether to cleanup resource it taken or not? for example:
>>
>>   int bpf_object__load(struct bpf_object *obj, bool clean);
>>
>> then we can further wrap it by a macro:
>>
>>   #define bpf_object__load_clean(o) bpf_object__load(o, true)
>>
>> If 'clear' is true, after loading resources will be freed, and the same
>> object will be unable to reload again after unload. B doing this we can
>> avoid adding a new function.
> imo that would be an ugly API. You only want to do that to have
> one less library API function? I think it's cleaner to let user of
> the library call it when necessary.
> Or do cleaning unconditionally. I don't see a use case when the
> same set of maps and programs would need to be loaded twice into the kernel.

OK. Let bpf_object__load() clean resources unconditionally.

Thank you.



  reply	other threads:[~2015-05-29  4:00 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-27  5:19 [RFC PATCH v4 00/29] perf tools: filtering events using eBPF programs Wang Nan
2015-05-27  5:19 ` [RFC PATCH v4 01/29] tools: Add __aligned_u64 to types.h Wang Nan
2015-05-27 13:00   ` Arnaldo Carvalho de Melo
2015-05-28  0:28     ` Wangnan (F)
2015-05-28  0:31       ` Arnaldo Carvalho de Melo
2015-05-27  5:19 ` [RFC PATCH v4 02/29] perf tools: Move linux/kernel.h to tools/include Wang Nan
2015-05-27 13:03   ` Arnaldo Carvalho de Melo
2015-05-27  5:19 ` [RFC PATCH v4 03/29] perf tools: Move linux/{list.h,poison.h} " Wang Nan
2015-05-27 13:15   ` Arnaldo Carvalho de Melo
2015-05-27 13:21     ` Arnaldo Carvalho de Melo
2015-05-27 15:30       ` Arnaldo Carvalho de Melo
2015-05-27  5:19 ` [RFC PATCH v4 04/29] bpf tools: Introduce 'bpf' library to tools Wang Nan
2015-05-27  5:19 ` [RFC PATCH v4 05/29] bpf tools: Allow caller to set printing function Wang Nan
2015-05-29 13:35   ` Namhyung Kim
2015-05-27  5:19 ` [RFC PATCH v4 06/29] bpf tools: Open eBPF object file and do basic validation Wang Nan
2015-05-28  1:44   ` Alexei Starovoitov
2015-05-27  5:19 ` [RFC PATCH v4 07/29] bpf tools: Check endianess and make libbpf fail early Wang Nan
2015-05-28  1:45   ` Alexei Starovoitov
2015-05-27  5:19 ` [RFC PATCH v4 08/29] bpf tools: Iterate over ELF sections to collect information Wang Nan
2015-05-28  1:46   ` Alexei Starovoitov
2015-05-27  5:19 ` [RFC PATCH v4 09/29] bpf tools: Collect version and license from ELF sections Wang Nan
2015-05-28  1:48   ` Alexei Starovoitov
2015-05-28  3:34     ` Wangnan (F)
2015-05-28  5:51       ` Alexei Starovoitov
2015-05-27  5:19 ` [RFC PATCH v4 10/29] bpf tools: Collect map definitions from 'maps' section Wang Nan
2015-05-28  1:53   ` Alexei Starovoitov
2015-05-28  2:03     ` Wangnan (F)
2015-05-28  2:28       ` Alexei Starovoitov
2015-05-28  3:09         ` Wangnan (F)
2015-05-28  6:09           ` Alexei Starovoitov
2015-05-28  7:14             ` Wangnan (F)
2015-05-29  3:35               ` Alexei Starovoitov
2015-05-29  3:59                 ` Wangnan (F) [this message]
2015-06-01  2:12                 ` Namhyung Kim
2015-06-01  5:19                   ` Wangnan (F)
2015-06-01  6:03                     ` Namhyung Kim
2015-06-01 13:01                       ` Arnaldo Carvalho de Melo
2015-05-27  5:19 ` [RFC PATCH v4 11/29] bpf tools: Collect symbol table from SHT_SYMTAB section Wang Nan
2015-05-27  5:19 ` [RFC PATCH v4 12/29] bpf tools: Collect eBPF programs from their own sections Wang Nan
2015-05-27  5:19 ` [RFC PATCH v4 13/29] bpf tools: Collect relocation sections from SHT_REL sections Wang Nan
2015-05-27  5:19 ` [RFC PATCH v4 14/29] bpf tools: Record map accessing instructions for each program Wang Nan
2015-05-27  5:19 ` [RFC PATCH v4 15/29] bpf tools: Add bpf.c/h for common bpf operations Wang Nan
2015-05-28  1:55   ` Alexei Starovoitov
2015-05-29 14:44   ` Namhyung Kim
2015-05-27  5:19 ` [RFC PATCH v4 16/29] bpf tools: Create eBPF maps defined in an object file Wang Nan
2015-05-28  1:57   ` Alexei Starovoitov
2015-05-27  5:19 ` [RFC PATCH v4 17/29] bpf tools: Relocate eBPF programs Wang Nan
2015-06-01  5:32   ` Namhyung Kim
2015-06-01  6:36     ` Wangnan (F)
2015-05-27  5:19 ` [RFC PATCH v4 18/29] bpf tools: Introduce bpf_load_program() to bpf.c Wang Nan
2015-05-28  2:14   ` Alexei Starovoitov
2015-05-27  5:19 ` [RFC PATCH v4 19/29] bpf tools: Load eBPF programs in object files into kernel Wang Nan
2015-05-27  5:19 ` [RFC PATCH v4 20/29] bpf tools: Introduce accessors for struct bpf_program Wang Nan
2015-05-27  5:19 ` [RFC PATCH v4 21/29] bpf tools: Introduce accessors for struct bpf_object Wang Nan
2015-05-27  5:19 ` [RFC PATCH v4 22/29] bpf tools: Link all bpf objects onto a list Wang Nan
2015-05-27  5:19 ` [RFC PATCH v4 23/29] perf tools: Make perf depend on libbpf Wang Nan
2015-05-27  5:19 ` [RFC PATCH v4 24/29] perf record: Enable passing bpf object file to --event Wang Nan
2015-05-27  5:20 ` [RFC PATCH v4 25/29] perf tools: Parse probe points of eBPF programs during preparation Wang Nan
2015-05-27  5:20 ` [RFC PATCH v4 26/29] perf record: Probe at kprobe points Wang Nan
2015-05-27  5:20 ` [RFC PATCH v4 27/29] perf record: Load all eBPF object into kernel Wang Nan
2015-05-27  5:20 ` [RFC PATCH v4 28/29] perf tools: Add bpf_fd field to evsel and config it Wang Nan
2015-05-27  5:20 ` [RFC PATCH v4 29/29] perf tools: Attach eBPF program to perf event Wang Nan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5567E416.2080206@huawei.com \
    --to=wangnan0@huawei.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=brendan.d.gregg@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=dsahern@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=paulus@samba.org \
    --cc=pi3orama@163.com \
    --cc=xiakaixu@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.