I have this funny feeling that no-one has ever successfully used the hfs
(Apple) filesystem on ARMLinux. I'd like to fix it.
I think the problem is to do with structure sizes and padding...
HFS defines:
/* Typedefs for unaligned integer types */
typedef unsigned char hfs_byte_t;
typedef unsigned char hfs_word_t[2];
typedef unsigned char hfs_lword_t[4];
and (for example)
struct NodeDescriptor {
hfs_lword_t ndFLink; /* (V) Number of the next node at this level */
hfs_lword_t ndBLink; /* (V) Number of the prev node at this level */
hfs_byte_t ndType; /* (F) The type of node */
hfs_byte_t ndNHeight; /* (F) The level of this node (leaves=1) */
hfs_word_t ndNRecs; /* (V) The number of records in this node */
hfs_word_t ndResv2; /* Reserved */
};
because it appears that the Apple disk format uses 16 bit aligned 32 bit
quantities, and the above is an attempt to make things happy on Alphas.
However, I find that my problems mounting my disk start with a line:
prev = sizeof(struct NodeDescriptor);
which is 16. :-)
[At this first problem point in bnode.c it doesn't rely on how adjacent
structures pack in memory, only how big something is using sizeof()]
If I count correctly there are 14 bytes (chars) in the structure. So
am I right in thinking that:
ARM gcc pads structures out to the next 4 bytes
i386 gcc doesn't
Alpha gcc doesn't
Hence the above struct has size 14 on most architectures?
[If my assumption is correct, what's the best platform independent way
of getting the sizes of the structures - something like:
offsetof(struct NodeDescriptor,ndResv2)+sizeof(nd->ndResv2))
where nd is of type struct NodeDescriptor *
Or is the whole scheme used by hfs ANSIly flawed, and for true
portability it can only use one contiguous char array, as structures
can be padded between any members?
]
Nick
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for ++
++ kernel-related discussions. ++
