Confusion between variable definition and declaration - __read_mostly macro not handled on Linux

[sk-buff]

When I searched the identifier pfifo_fast_ops in the newest kernel v5.12-rc5, I found the result confused the definition and the declaration of the identifier. The result showed pfifo_fast_ops is defined at include/net/sch_generic.h, line 574 (as a externvar). However, it's a declaration of a extern variable instead of a definition, which is like the following:

extern struct Qdisc_ops pfifo_fast_ops;

The definition of pfifo_fast_ops actually locates in net/sched/sch_generic.c, line 782 and is showed in the Referenced part in the result.The definition is:

struct Qdisc_ops pfifo_fast_ops __read_mostly = {
	.id		=	"pfifo_fast",
	.priv_size	=	sizeof(struct pfifo_fast_priv),
	.enqueue	=	pfifo_fast_enqueue,
	.dequeue	=	pfifo_fast_dequeue,
	.peek		=	pfifo_fast_peek,
	.init		=	pfifo_fast_init,
	.destroy	=	pfifo_fast_destroy,
	.reset		=	pfifo_fast_reset,
	.dump		=	pfifo_fast_dump,
	.change_tx_queue_len =  pfifo_fast_change_tx_queue_len,
	.owner		=	THIS_MODULE,
	.static_flags	=	TCQ_F_NOLOCK | TCQ_F_CPUSTATS,
};

I don't know whether it's a mistake, plz check it :)

[CS-cwhite]

What ctags output do you get for that symbol in sch_generic.h and sch_generic.c? Elixir relies on ctags to make those distinctions.

[fstachura]

This looks like a ctags issue. __read_mostly is recognized as a variable name, probably because it's the last part of the declaration, while it's actually a macro that usually expands to __section(".data..read_mostly"). The issue persists on ctags master.
Adding -I __read_mostly to mark __read_mostly as a special identifier fixes the issue. We can handle this in projects, but I have also proposed a more general project-settings framework in new-lexers.

$ ./ctags -x sch_generic.c | grep 782
__read_mostly    variable    782 sch_generic.c struct Qdisc_ops pfifo_fast_ops __read_mostly = {

[tleb]

Keeping an up-to-date list of macros that generate (important) functions sounds OK. But keeping a list of special identifiers? Let's see what it looks like:

⟩ git describe
v6.14-rc4

⟩ rg 'struct .* = \{' | cut -d: -f2- | \
    awk '$0 ~ " __" {x = substr($0, index($0, " __")+1); x = substr(x, 1, index(x, " ")); print x}' | \
    sort | uniq -c | sort -n | awk '$1 > 1'
      2 __aio_sigset	ksig
      2 __aligned(sizeof(struct
      2 __argv
      2 __attribute__((aligned(16)))
      2 __compat_aio_sigset
      2 __envp
      2 __find_tracepoint_cb_data
      2 __initdata_or_module
      2 __kernel_old_timeval
      2 __line_walk_param
      2 __pins##_muxregs[]
      2 __prci_clock
      2 __tracepoint_ext_##_name
      2 __user_cap_data_struct
      2 __vdso_info
      3 __fops
      3 __group_key
      3 __kernel_timespec
      3 __rcu
      3 __text
      4 __ext_steer_reg
      4 __guc_mmio_reg_descr_group
      4 __net_initconst
      4 __refconst
      4 __user_cap_header_struct
      5 ____cacheline_aligned
      5 __cacheline_aligned
      5 __kvm_pmu_event_filter
      5 __VA_ARGS__
      6 __initconst_or_module
      8 __driver
      8 __free(path_put)
      8 __sk_buff
      9 __prci_wrpll_data
     10 __prel64_initconst
     12 __name
     13 __ITEM_NAME(_type,
     14 __used
     19 __clone_args
     21 __guc_mmio_reg_descr
     32 __net_initdata
     65 __initmv
     84 __refdata
    163 __ro_after_init
    469 __maybe_unused
    487 __read_mostly
    941 __initdata
   2002 __initconst

That doesn't feel too massive. But it would have to be kept updated. At least we should put the decisionmaking for picking the attributes inside the commit message so we have an easy reference if we want to update the list later down the road.

[fstachura]

In the end I don't think this is something that can be reliably implemented on ctags side. Seems that you can have an arbitrary number of identifiers/macro calls between type and variable name, and between variable name and equals sign.

That doesn't feel too massive. But it would have to be kept updated. At least we should put the decisionmaking for picking the attributes inside the commit message so we have an easy reference if we want to update the list later down the road.

I think we will have to do some maintenance for most important projects either way. For example Zephyr does not promise west to be compatible with all future versions, major version bumps can break APIs. (I think "west API" does not refer to the manifest format, but I won't be surprised if it's included).
So I yeah, I would keep a list of special identifiers to be passed to -I for the Kernel.

[CS-cwhite]

I would keep a list of special identifiers to be passed to -I

I've had to do the same on other projects that consume ctags data, so this makes sense to me.