On Wed, Dec 07, 2022 at 01:52:07PM -0500, Dave Marchevsky wrote: > On 12/6/22 8:41 PM, Alexei Starovoitov wrote: > > On Tue, Dec 06, 2022 at 03:09:51PM -0800, Dave Marchevsky wrote: > >> Many of the structs recently added to track field info for linked-list > >> head are useful as-is for rbtree root. So let's do a mechanical renaming > >> of list_head-related types and fields: > >> > >> include/linux/bpf.h: > >> struct btf_field_list_head -> struct btf_field_datastructure_head > >> list_head -> datastructure_head in struct btf_field union > >> kernel/bpf/btf.c: > >> list_head -> datastructure_head in struct btf_field_info > > > > Looking through this patch and others it eventually becomes > > confusing with 'datastructure head' name. > > I'm not sure what is 'head' of the data structure. > > There is head in the link list, but 'head of tree' is odd. > > > > The attemp here is to find a common name that represents programming > > concept where there is a 'root' and there are 'nodes' that added to that 'root'. > > The 'data structure' name is too broad in that sense. > > Especially later it becomes 'datastructure_api' which is even broader. > > > > I was thinking to propose: > > struct btf_field_list_head -> struct btf_field_tree_root > > list_head -> tree_root in struct btf_field union > > > > and is_kfunc_tree_api later... > > since link list is a tree too. > > > > But reading 'tree' next to other names like 'field', 'kfunc' > > it might be mistaken that 'tree' applies to the former. > > So I think using 'graph' as more general concept to describe both > > link list and rb-tree would be the best. > > > > So the proposal: > > struct btf_field_list_head -> struct btf_field_graph_root > > list_head -> graph_root in struct btf_field union > > > > and is_kfunc_graph_api later... > > > > 'graph' is short enough and rarely used in names, > > so it stands on its own next to 'field' and in combination > > with other names. > > wdyt? > > > > I'm not a huge fan of 'graph', but it's certainly better than > 'datastructure_api', and avoids the "all next-gen datastructures must do this" > implication of a 'ng_ds' name. So will try the rename in v2. fwiw I don't like 'next-' bit in 'next-gen ds'. A year from now the 'next' will sound really old. Just like N in NAPI used to be 'new'. > (all specific GRAPH naming suggestions in subsequent patches will > be done as well) > > list 'head' -> list 'root' SGTM as well. Not ideal, but alternatives > are worse (rbtree 'head'...) Thanks!
