Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752305AbbEYLrs (ORCPT ); Mon, 25 May 2015 07:47:48 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:33605 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751424AbbEYLrr (ORCPT ); Mon, 25 May 2015 07:47:47 -0400 Message-ID: <55630BB5.9020702@huawei.com> Date: Mon, 25 May 2015 19:47:01 +0800 From: "Wangnan (F)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jiri Olsa CC: , , , , , , , , , , , , , Subject: Re: [RFC PATCH v3 30/37] perf bpf: Add bpf-loader and open ELF object files References: <1431860222-61636-1-git-send-email-wangnan0@huawei.com> <1431860222-61636-31-git-send-email-wangnan0@huawei.com> <20150522172435.GH6609@krava.redhat.com> In-Reply-To: <20150522172435.GH6609@krava.redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.66.109] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1494 Lines: 53 On 2015/5/23 1:24, Jiri Olsa wrote: > On Sun, May 17, 2015 at 10:56:55AM +0000, Wang Nan wrote: > > SNIP > >> +#define DEFINE_PRINT_FN(name, level) \ >> +static int libbpf_##name(const char *fmt, ...) \ >> +{ \ >> + va_list args; \ >> + int ret; \ >> + \ >> + va_start(args, fmt); \ >> + ret = veprintf(level, verbose, pr_fmt(fmt), args);\ >> + va_end(args); \ >> + return ret; \ >> +} >> + >> +DEFINE_PRINT_FN(warning, 0) >> +DEFINE_PRINT_FN(info, 0) >> +DEFINE_PRINT_FN(debug, 1) >> + >> +static bool libbpf_inited = false; >> + >> +#define MAX_OBJECTS 128 >> + >> +struct { >> + struct bpf_object *objects[MAX_OBJECTS]; >> + size_t nr_objects; >> +} params; > apart from that we dont like this kind of static stuff, this seems like > nice case for having simple handler like 'struct bpf_objects' carrying > the above data.. what do I miss? I want to avoid fragmented memory allocation for storing bpf_object pointers. Storing them together into an array can make code simpler. I think I can made something like 'struct bpf_object *bpf_next_object(obj)' in libbpf so we can iterate over each loaded bpf objects, then this array and nr_objects can be hidden. > also params should actually be static right? > > jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/