On 2015-12-01 at 7:37 ron minnich wrote: > Interesting discussion! I actually ran into rob's post when I was > chasing down some problems in coreboot in 2013. > > A very experienced OS guy wrote code to manipulate ELF and other such > files, and did the common ntohl/htonl thing, and (in one case) got it > backwards, and (in another case) forgot to use them. The code all > worked just fine on x86 for years, broke on other things, and > serialized data in a manner that worked by pure luck -- until we went > multiarchitecture again. > > I think the key sentence is here: "Whenever I see code that asks what > the native byte order is, it's almost certain the code is either > wrong or misguided." [note: almost certain. Nothing's absolute.]
I agree with that. The main thing to me seems to be to use helpers all the time. That way you're not thinking about what your host endianness is. > That has been my experience too, but I had not thought about it in > quite those terms until I ran across that post. To fix the coreboot > problem, I wrote a little conversion library based on the principles > laid out in that post and things got fixed.Nobody does open coding; > they use the library. But the functions in that library are dead > simple because they use these techniques. And, when we add a new > architecture, as we've done 4 times now in 3 years, no new library > code need be written, and nothing changes. That's nice. I don't have > to add new #ifdef cases and so on. The same code just compiles and > works correctly. That's a nice benefit - not having to add new arch/endian files, or having to #define BIGENDIAN or whatever. I think a nice middle ground is to have arch/endian.h, and every arch can do whatever they want. One thing arch/endian.h can do is #include generic-portable-endian-from-rob.h, and not worry about it. x86 can do something else if it wants for it's perf. ARM can do what it wants, etc. Then we can also easily swap out the implementations and measure the result. As a side note, one of Drew's improvements to the network stack relied on assuming aligned moves. Checkout out ipmove() and ipcmp() (k/i/ip.h). For the most part, IP addrs are aligned, but there's a chance they aren't (I think). > The technique he suggests is portable; endian, word size, and > alignment neutral; and very easy to read -- no cpp #ifdef stuff > needed, just one simple function. You get to use the same code for > all architectures. And, big bonus, on good compilers, there's no > penalty. Let me know when I can use one of those compilers. =) > At the same time, as always, there's lots of room for disagreement > for good reasons. That's what makes horse races :-) Haha. Or a good giraffe fight! Barret -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
