[lkml]   [2000]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Large File support and blocks.

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.133 / U:0.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site