Hi Mike,
On Thu, 19 Jul 2012 00:29:23 -0400, Mike Frysinger vapier@gentoo.org wrote:
On Monday 02 July 2012 12:14:40 Måns Rullgård wrote:
It's slightly more complicated than that. Data can be misaligned for a variety of reasons:
- Errors in software.
- Specified by a file format or communication protocol.
- Deliberately misaligned by the compiler.
Misaligned data of type 1 should of course be fixed properly, not worked around in any way.
it's also a reliability aspect. people don't write bug free software, not bug free protocols, nor bug free compilers. when misalignment does happen in the field, it's a hell of a lot better if the software continued to execute correctly rather than randomly triggered an exception. -mike
Nitpick: this is robustness, not reliability.
That being said, yes, this robustness is desirable when you do not control all of the SW running on the product; Linux, for instance, will have to execute processes which were built with any old (or new) compiler settings, thus the Linux folks have to make sure the kernel won't fail running those.
But the only uncontrolled SW U-Boot runs is its payload -- typically the kernel image -- which are usually very cautious in what they assume they can do, thus are unlikely to perform unaligned accesses.
(pasting your other comment)
simply search the kernel for get_unaligned then. there are plenty of examples in there. granted, many apply to stacks that don't show up in u-boot (yet?) such as bluetooth, wireless, and irda, but i'm pretty sure TCP/IPv4 has a few edge cases too.
I'll have a look, if only to lament that protocol are not what they used to be in the old days. :)
Anyway: as I said: performing *controlled* unaligned accesses for external reasons other than bugs is fine with me. Having our own get_unaligned() in such places would be fine with me.
Amicalement,