> Package: mac-fdisk
> Version: 0.1-13
>
> On the experimental Debian-PPC64
> (http://debian-ppc64.alioth.debian.org/), mac-fdisk fails on
> initialization.
What's the status of ppc64 anyway? I thought even Debian was going to
integrate 64 bit binaries into the regular powerpc architecture now?
> banana:~# mac-fdisk
> (null): Size of partion map entry (944) is not equal to block size
> (512)
>
> source is in pdisk.c:
>
> if (sizeof(DPME) != PBLOCK_SIZE) {
> fatal(-1, "Size of partion map entry (%d) "
> "is not equal to block size (%d)\n",
> sizeof(DPME), PBLOCK_SIZE);
> }
>
> There are 3 independent bugs which cause this malfunction:
>
> 1. in dpme.h, "u32" is defined as "unsigned long", which is 64 bits
> wide on ppc64 - I believe "unsigned int" should be safe on all
> relevant platforms, or just use the C99 types (u_int32_t).
I doubt unsigned int is safe under all circumstances. But I'll give it a
try.
> 2. "struct dpme" is not packed, and its members are set to the wrong
> alignment on ppc64
Since struct dpme describes the on-disk data format, there's nothing we
can do about packing or alignment on ppc64. Quote dpme.h:
"Each entry is (and shall remain) 512 bytes long."
How does the kernel mac partition table support work on ppc64?
> 3. "struct dpme" contains several pointers, which are also 64 bits
> wide on ppc64. Who writes this kind of code??
Apple, at a time far back when 64 bit processors were of no interest to
them (the Alpha was available but nothing else).
The pointers are not used by any Linux code - they describe load and start
addresses for boot blocks only. We can easily convert these to unsigned 32
bit types. If you have a problem with 32 bit alignment on ppc64, please
write appropriate pack and unpack functions for use by ppc64.
I've prepared a new upload which should fix the issue. Please test.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
