Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753949AbbEUA1y (ORCPT ); Wed, 20 May 2015 20:27:54 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:38941 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753335AbbEUA1w (ORCPT ); Wed, 20 May 2015 20:27:52 -0400 Message-ID: <555D25A3.9010507@huawei.com> Date: Thu, 21 May 2015 08:24:03 +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: Alexei Starovoitov , , , , , , , , , , CC: , , Subject: Re: [RFC PATCH v3 06/37] bpf tools: Introduce 'bpf' library to tools References: <1431860222-61636-1-git-send-email-wangnan0@huawei.com> <1431860222-61636-7-git-send-email-wangnan0@huawei.com> <555A22DB.5040200@plumgrid.com> <555C03F7.4040206@huawei.com> <555C1A97.3060805@plumgrid.com> In-Reply-To: <555C1A97.3060805@plumgrid.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit 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: 2750 Lines: 77 在 2015/5/20 13:24, Alexei Starovoitov 写道: > On 5/19/15 8:48 PM, Wangnan (F) wrote: >> >>>> + >>>> +# Version of eBPF elf file >>>> +FILE_VERSION = 1 >>> >>> what that comment suppose to mean? >> >> The format of eBPF objects can be improved in futher. A version number >> here is the precaution of backward compatibility. However this patch >> doesn't >> utilize it. >> >> I'd like to append a 'format' section into eBPF object format to let >> libbpf know >> the version of the object. What do you think? > > I don't think it will help. > Version number is quite inconvenient. > perf_event_attr and bpf_attr are using 'size' instead, since the only > way keep to backward compatibility is to force new additions to preserve > old fields. The notion that 'new version number can start fresh' doesn't > really work, because it means duplicated code. In this case, in libbpf. > I don't think we want 'if (elf_version == X) parse sections this way' > type of code. > iproute2 already reserved 'classifier' and 'action' > names and I think 'kprobe' and 'socket' are good enough prefixes for > BPF_PROG_TYPE_KPROBE and BPF_PROG_TYPE_SOCKET_FILTER programs as well. Do you think we should classify kprobe/socket programs in libbpf layer instead of perf? In my current implementation, type of a program is determined by perf by parsing names of corresponding sections. Format of section names should be part of interface between perf (and iproute2 and others) and eBPF programs. What libbpf should do is to fetch those names and give them to caller, let caller decide the type of programs. Therefore, if the program is written for perf, writer of program even don't need to think about kprobe/socket program type since in perf currently we can only use kprobe program. (Currently "config" section is special, but as you suggested I decide to drop it in next version.) > So the prefix to indicate the program type is already settled. > What comes after the prefix is tbd. > I proposed 'kprobe/perform_write(void*, void*, long long)' > style for vmlinux without debug info and > 'kprobe/perform_write+122(file->f_mapping->a_ops, bytes, offset)' > with debug. It looks flexible enough and can be extended with > new features later. Now section name has similary format as 'perf probe' because I think by doing this we can avoid inventing a new syntax for eBPF programs. What do you think? > I don't think 'config', 'format' sections are needed. > You won't see them in v4 :) Thank you. -- 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/