On Mon, Jun 17, 2019 at 04:09:26PM +0000, Jerin Jacob Kollanukkaran wrote:
> > -----Original Message-----
> > From: Neil Horman <nhor...@tuxdriver.com>
> > Sent: Thursday, June 13, 2019 7:54 PM
> > To: dev@dpdk.org
> > Cc: Neil Horman <nhor...@tuxdriver.com>; Jerin Jacob Kollanukkaran
> > <jer...@marvell.com>; Bruce Richardson <bruce.richard...@intel.com>;
> > Thomas Monjalon <tho...@monjalon.net>
> > Subject: [EXT] [PATCH v2 09/10] octeonx: mark internal functions with
> > __rte_internal
> >
> > +
> > +DPDK_18.05 {
> > + global:
> > + octeontx_logtype_mbox;
>
> It should move to INTERNAL. Right?
>
So, thats an interesting symbol that we should probably discuss more.
octeontx_logtype_mbox is actually a global int variable, not a function, and
__rte_internal only works on the latter type of symbol (i.e. the
__attribute__(error(...)) tag only applies to functions. I could create an
__rte_internal_data data, that can do something simmilar for global variables,
but it occured to me that perhaps global variables should not be a method of
communication between internal libraries like this (opting instead for getter
and setter methods to protect it, and then exempting those functions with
__rte_internal). I believe David mentioned something along these lines as well
previously, but I didn't want to go making changes like that without a more
focused discussion, so I opted to leave global variables in place for now.
Thoughts on how to address this case?
Neil
> > +
> > + local: *;
> > +};
> > --
> > 2.20.1
>
>
