"Is all in the name"

[Stephen Hemminger]

The exploration of re-enabling compiler warnings across DPDK has led me down into
why format overflow warnings are disable in lib including EAL.

It turns out that current code is rather sloppy about putting suffixes on names
and the limits are rather small.

The limit on name size for a memzone is 32 character, then ring code adds 3
characters so rings can only be 29 characters, then hash adds 7 character prefix
so hash table name limit is 22 characters...

There is also the issue that file name prefix is used to create unix domain socket
paths. Linux and FreeBSD inherit a limit of 108 characters for that. Which means
the allowable maximum limit of file name prefix is much smaller than the advertised
PATH_MAX (4096).

For the short term, the plan is to add the missing length checks for both each
libraries name, and for the file prefix. With release note because it is sure to
break some application that was getting by before.

For the long term, I there are a couple of options to expand the names.
  1. Rearrange memzone to use flexible array length and put name at
     end of struct. This would allow arbitrarily large memzones.
      - should also hide the actual definition of rte_memzone?
      - should also not mark memzone as packed; packed generates bad code
        some times and if you just arrange elements right there is no problem.
  2. Bump memzone name size up to something much larger like 128

It would also help if there was some convention about naming.
The logical option would be to use a dotted format like:
        zone name = ring.hash.qsbr.XXXXX
rather than current practice of arbitrary prefixes usage with _.
But this would not be enforced just DPDK wide convention.

Can't fix the file prefix/unix domain socket limit, but it should be documented
and enforced.