Good one
Good one
Posted Sep 26, 2013 16:17 UTC (Thu) by deater (subscriber, #11746)In reply to: Good one by etienne
Parent article: A perf ABI fix
Not a problem in most cases, but perf_event describes some bitfields
such as struct perf_branch_entry that get written to disk directly.
So if you record a session, then move it to an opposite-endian machine and try to read it back in you have problems.
Posted Sep 27, 2013 12:05 UTC (Fri)
by etienne (guest, #25256)
[Link]
On my side of the world, you do have little-endian system and BI-endian systems: the processor may be big-endian, but then it always has to interact with at least one little-endian subsystem (could be as simple as a PCI card, more usually most subsystems).
I still prefer:
Good one
Then, they added stuff at the virtual memory layer to describe that memory mapped area as either little or big endian, which solves a small part of the problem, two bit fields still increment as 0b00, 0b10, 0b01, 0b11.
Then, big endian processor sort of disappeared.
struct status {
#ifdef LITTLE_ENDIAN
unsigned b1:1, b2:1, b3:1, unused:29;
unsigned xx;
#else
unsigned xx;
unsigned unused:29, b3:1, b2:1, b1:1;
#endif
}
than the 40 equivalent lines of #define, if I have a lot of those status.