Re: [mpls-linux-general] Endianess and bitfields

[Georg K. <gk...@gi...>]

Hi Jim,

> If the code was relying on the location of the bits within the unsigned
> int, then I would have to take into account endianess. 

yes, you are right with that. But the MPLS kernel code assigns outgoing labels
as unsigned ints as you can see from the following code:

------------------------------------------
static unsigned int mpls_out_info_key = 1;

unsigned int mpls_get_out_key(void) {
    mpls_out_info_key++;
    return mpls_out_info_key;
}
------------------------------------------

These keys are then printed as bit fields in the mpls_print_key() function. 
That is exactly what we are seeing: different prints on Pentium and PPC:

Pentium log:

mpls_add_out_label: enter
mpls_out_info_hold: enter
mpls_out_info_hold: new count 1
mpls_out_info_hold: exit
Key UNKNOWN 00000005
mpls_add_out_label: enter


and the PPC Log:
mpls_add_out_label: enter
mpls_out_info_hold: enter
mpls_out_info_hold: new count 1
mpls_out_info_hold: exit
Key GEN 1 0
mpls_add_out_label: enter


In both cases the key was assigned via the function mpls_get_out_key() to 
the value 5!

> ... Since the code only
> uses the bit fields to form a unique key and does not try to access the bit
> values once they have been converted to a key, there is no need to be 
> concerned about byte-ordering.

So that is not true. The keys are assigned in the above case as intergers and
afterwards (in the print function) interpreted as bitfields.

Please also note that I am not concerned about the byte ordering, but about the
bitfield orders which is a different issue! It means that the first bit field
is the most significant bitfield or the least significant one!

Kind regards,
Georg Klug