> [...]
> > +INTERNAL {
> > + global:
> > +
> > + rte_mem_lock;
> > + rte_mem_map;
> > + rte_mem_page_size;
> > + rte_mem_unmap;
> > +};
>
> Not sure why these functions are internal.
> They may be useful for DPDK applications.
> We would need to add the file in doxygen index.
>
Not sure if they are in DPDK scope, apart from rte_mem_lock, which
generalizes rte_mem_lock_page already in rte_memory.h. What may be typical
use cases for data-plane apps? I can see testpmd using mmap for allocating
external memory (because of possible use of hugepages), does it need these
functions exposed?
> If we want to keep them internal, we should add a doxygen marker
> @internal.
>
IIRC, it were you who proposed making them internal instead of
experimental. And internal symbols can always be exposed later.
> > +#include <rte_eal_memory.h>
>
> I think we should find a better file name for these wrappers.
> "EAL memory" means DPDK memory allocator in my mind.
> We need a file name which is about OS-independent wrappers,
> or libc wrappers.
> What about rte_libc_mem.h? rte_mem_os.h? something else?
See above, but anyway, "libc" is non-generic.
