> -----Original Message-----
> From: Neil Horman <nhor...@tuxdriver.com>
> Sent: Tuesday, June 18, 2019 12:44 AM
> To: Jerin Jacob Kollanukkaran <jer...@marvell.com>
> Cc: dev@dpdk.org; Bruce Richardson <bruce.richard...@intel.com>;
> Thomas Monjalon <tho...@monjalon.net>
> Subject: [EXT] Re: [PATCH v2 09/10] octeonx: mark internal functions with
> __rte_internal
>
> 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?
The runtime log infrastructure currently depends on global variables in DPDK.
Either way is fine with me(Introducing getter/setter vs current scheme). But it
has
to be addressed for completeness.
>
> Neil
>
> > > +
> > > + local: *;
> > > +};
> > > --
> > > 2.20.1
> >
> >
