Re: [patch 1/1] dm: fix printk errors about whether %lu/%Lu is right for sector_t - revised
From: BlaisorBlade
Date: Mon Oct 25 2004 - 16:29:19 EST
On Friday 22 October 2004 11:53, Andrew Morton wrote:
> blaisorblade_spam@xxxxxxxx wrote:
> > The Device Manager code barfs when sector_t is 64bit wide (i.e. an u64)
> > and CONFIG_LBD is off. This happens on printk(), resulting in wrong
> > memory accesses, but also on sscanf(), resulting in overflows (because it
> > uses %lu for a long long in this case). And region_t, chunk_t are
> > typedefs for sector_t, so we have warnings for these, too.
> This patch caused the x86_64 build to puke: "Not allowed to define
> CONFIG_LBD on this architecture" or some such.
Yes, there is an #error directive for this.
Who would ever need to use CONFIG_LBD when sector_t is already 64-bit? So this
is flagged as an error (feel free to remove that, if you know a good reason).
In fact, this is your fault, given both the 2.6.9 kernel and the 2.6.10-rc1
one:
config LBD
bool "Support for Large Block Devices"
depends on X86 || MIPS32 || PPC32 || ARCH_S390_31 || SUPERH
help
Say Y here if you want to attach large (bigger than 2TB) discs to
your machine, or if you want to have a raid or loopback device
bigger than 2TB. Otherwise say N.
So if you define LBD on a x86_64 kernel, you get to keep the pieces.
A make oldconfig would probably help - don't you think so?
> I'd much prefer that you simply remove SECTOR_FORMAT completely.
Impossible - doing a scanf and then copying the value is much uglier. I just
add 5 lines of code to avoid the problem, while removing the silly
HAVE_SECTOR_T trick and moving the CONFIG_LBD handling to arch-independent
code.
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/