My opinion is that if they aren't performance-critical, the best fix is
to just remove the "printk()" that prints out the information. In many
cases the unaligned accesses are best handled by trapping (strange msdos
fs layout etc - the DOS fs isn't exactly a stellar performer even
_without_ the trap overhead). Only if you get _huge_ amounts of traps
does it make sense to try to track them down (that would indicate that
the traps happen in a critical path that really needs to be fixed).
> Another question while I've (hopefully) gotten your attention.
> While debugging Milo I discovered a problem with gcc 2.7.0
> doing sign extension for unsigned data and wanted to ask
> if perhaps the constants should have a 'UL' tacked on to
> them (I had to apply the following patch the 'asm-alpha/system.h'
> to fix a problem).
> Thanks,
> Bill V.
>
> 8<----------8<----------8<----------8<----------8<----------8<----------8<----
> --- linux/drivers/block/ide-cd.c.orig Fri Dec 1 03:24:48 1995
> +++ linux/drivers/block/ide-cd.c Fri Dec 1 03:26:00 1995
> @@ -99,6 +99,7 @@
> #include <linux/cdrom.h>
> #include <asm/irq.h>
> #include <asm/io.h>
> +#include <asm/segment.h>
>
> #define _IDE_CD_C /* used in blk.h */
> #include "ide.h"
> --- linux/include/asm-alpha/system.h.orig Sat Nov 25 09:54:56 1995
> +++ linux/include/asm-alpha/system.h Fri Dec 1 02:44:13 1995
> @@ -21,12 +21,12 @@
>
> #define KERNEL_START 0xfffffc0000300000
> #define SWAPPER_PGD 0xfffffc0000300000
> -#define INIT_STACK 0xfffffc0000302000
> +#define INIT_STACK 0xfffffc0000302000UL
> #define EMPTY_PGT 0xfffffc0000304000
> #define EMPTY_PGE 0xfffffc0000308000
> #define ZERO_PGE 0xfffffc000030A000
>
> -#define START_ADDR 0xfffffc0000310000
> +#define START_ADDR 0xfffffc0000310000UL
> #define START_SIZE (2*1024*1024)
I _think_ that if gcc makes different code with and without the "UL" in
the above case, then gcc is broken. If I remember correctly, the C
standard explicitly says that integer constants get promoted to a type
that can hold them, which should make the integer constant
0xfffffc000030A000 be unsigned long even without the explicit "UL" at
the end.
Can anybody confirm my memory of the ANSI C standard? If so, I'd suggest
sending in a bug report to the gcc maintainers about this (but do check
this in the standard first).
Adding the UL shouldn't hurt, but quite frankly, if it is a gcc bug (and
I think it is), we'd be even better off fixing that instead - I think
it's a mistake to cater to compiler bugs.
Linus