On Sat, May 28, 2022 at 9:14 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>
> On Fri, 27 May 2022 15:15:21 +0800 menglong8.dong@xxxxxxxxx wrote:
> > +clean-files := dropreason_str.h
> > +
> > +quiet_cmd_dropreason_str = GEN $@
> > +cmd_dropreason_str = echo '\n\#define __DEFINE_SKB_DROP_REASON(FN) \' > $@;\
>
> echo -n
>
> > + sed -e '/enum skb_drop_reason {/,/}/!d' $< | \
> > + awk -F ',' '/SKB_DROP_REASON_/{printf " FN(%s) \\\n", substr($$1, 18)}' >> $@;\
> > + echo '' >> $@
>
> Trying to figure out when we're in the enum could be more robust
> in case more stuff gets added to the header:
>
> | awk -F ',' '/^enum skb_drop/ { dr=1; }
> /\}\;/ { dr=0; }
> /^\tSKB_DROP/ { if (dr) {print $1;}}'
>
> > +$(obj)/dropreason_str.h: $(srctree)/include/linux/dropreason.h
> > + $(call cmd,dropreason_str)
> > +
> > +$(obj)/skbuff.o: $(obj)/dropreason_str.h
>
> Since we just generate the array directly now should we generate
> a source file with it directly instead of generating a header with
> the huge define?
This seems to be a good idea, which is able to decouple the
definition of the array with skbuff.c. I'll try this.
Thanks!
Menglong Dong
