2016-12-08 13:59, Wiles, Keith: > > > On Dec 8, 2016, at 3:30 AM, Nélio Laranjeiro <nelio.laranje...@6wind.com> > > wrote: > > > > Hi all, > > > > Following previous discussions, I would like to gather requirements for > > v2, currently we have: > > > > 1. Introduction of new typedefs. > > 2. Modification of network headers. > > 3. Modification of rte_*_to_*() functions. > > > > Point 1. seems not to be an issue, everyone seems to agree on the fact > > having those types could help to document some parts of the code. > > I never stated these new types were useful in any way, I still believe > documentation of the code is the better solution then forcing yet another > restriction in submitting patches.
It would not be a restriction, just a help for those wanting to document some tricky parts by using these types. I see 2 usages: - in a struct: rte_be32_t speed; /**< 0 for speed negotiation */ instead of uint32_t speed; /**< [big endian] 0 for speed negotiation */ - in a function: rte_be32_t decode_speed (void *); [...] speed = rte_be_to_cpu_32(decode_speed()); It is difficult to reject something which could help a bit. Do you really think it would bring some confusion to have some code using these endianed-types?
