Messages in this thread |  | | Date | Mon, 4 Sep 2000 10:27:43 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: Large File support and blocks. |
| |
Hi,
On Fri, Sep 01, 2000 at 01:30:26PM +0300, Matti Aarnio wrote: > > Stephen, could you have a moment to look at the struct buffer_head {} > alignment matters ? And possible configure time change to make the > block number possibly a 'long long' variable ?
> Changeing field order might be doable now, while I definitely think that > changeing blocknumber variable type is 2.5 matter.
Right --- 2.5 will have to see a proper API for allowing 64-bit addressing on PCI buses too, for large memory Intel boxes. Right now we force bounce buffers in the ll_rw_block code, but we need a way to push that down to the driver if a given driver can do PCI64 or DAC addressing. I'd rather not touch things now, but wait until we're ready to do the job properly.
> opposed by Linus in the past (see <linux/fs.h> for it), putting > 64-bit integer in place of 32-bit one grows the head by one > extra padding (32 bits) at some architectures in addition to > the variable size growth. A "whoops!" I think. > > I think that for example SPARC32 has stricter alignment rules than > what i386 and 68k series processors have.
The compiler will usually deal with that by adding the necessary padding. You need this even on i386 --- ints get 32-bit aligned even if preceeded by a char or short type in a struct.
Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |