Re: [PATCH bpf-next v3 2/7] bpf: introduce bpf subcommand BPF_TASK_FD_QUERY

[Yonghong Song <yhs@fb.com>]

On 5/23/18 2:04 PM, Alexei Starovoitov wrote:
> On Wed, May 23, 2018 at 10:13:22AM -0700, Martin KaFai Lau wrote:
>>> +		__u32		prog_id;	/* output: prod_id */
>>> +		__u32		attach_info;	/* output: BPF_ATTACH_* */
>>> +		__u64		probe_offset;	/* output: probe_offset */
>>> +		__u64		probe_addr;	/* output: probe_addr */
>>> +	} task_fd_query;
>>>   } __attribute__((aligned(8)));
>>>   
>>>   /* The description below is an attempt at providing documentation to eBPF
>>> @@ -2458,4 +2475,14 @@ struct bpf_fib_lookup {
>>>   	__u8	dmac[6];     /* ETH_ALEN */
>>>   };
>>>   
>>> +/* used by <task, fd> based query */
>>> +enum {
>> Nit. Instead of a comment, is it better to give this
>> enum a descriptive name?
>>
>>> +	BPF_ATTACH_RAW_TRACEPOINT,	/* tp name */
>>> +	BPF_ATTACH_TRACEPOINT,		/* tp name */
>>> +	BPF_ATTACH_KPROBE,		/* (symbol + offset) or addr */
>>> +	BPF_ATTACH_KRETPROBE,		/* (symbol + offset) or addr */
>>> +	BPF_ATTACH_UPROBE,		/* filename + offset */
>>> +	BPF_ATTACH_URETPROBE,		/* filename + offset */
>>> +};
> 
> One more nit here.
> Can we come up with better names for the above?
> 'attach' is a verb. I cannot help but read above as it's an action
> for the kernel to attach to something and not the type of event
> where the program was attached to.
> Since we pass task+fd into that BPF_TASK_FD_QUERY command how
> about returning BPF_FD_TYPE_KPROBE, BPF_FD_TYPE_TRACEPOINT, ... ?

Okay will use BPF_FD_TYPE_*... which is indeed better than
BPF_ATTACH_*.