Re: [PATCH net 1/1] uapi: fix big endian definition of ipv6_rpl_sr_hdr

On Mon, 25 Jan 2021 22:11:35 +0100 (CET) Justin Iurman wrote:

quoted

quoted

quoted

If you meant the old/current one, well, I don't understand why the big endian definition would look like this:

#elif defined(__BIG_ENDIAN_BITFIELD)
   __u32    reserved:20,
       pad:4,
       cmpri:4,
       cmpre:4;

When the RFC defines the header as follows:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CmprI | CmprE |  Pad  |               Reserved                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The little endian definition looks fine. But, when it comes to big endian, you define fields as you see them on the wire with the same order, right? So the current big endian definition makes no sense. It looks like it was a wrong mix with the little endian conversion.  

Well, you don't list the bit positions in the quote from the RFC, and
I'm not familiar with the IETF parlor. I'm only  

Indeed, sorry for that. Bit positions are available if you follow the link to the RFC I referenced in the patch. It is always defined as network byte order by default (=BE).

quoted

comparing the LE
definition with the BE. If you claim the BE is wrong, then the LE is
wrong, too.  

Actually, no, it’s not. If you have a look at the header definition from the RFC, you can see that the LE is correct (valid translation from BE, the *new* BE in this patch).

Sigh, I see it now. Thanks!