lkml.org 
[lkml]   [2001]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 64-bit capable block device layer
On Wed, Mar 07, 2001 at 07:53:23PM +0100, Jens Axboe wrote:
> On Wed, Mar 07 2001, Rik van Riel wrote:
> > > > how would you feel about having the block device layer 64-bit
> > > > capable, so Linux can have block devices of more than 2GB in
> > > > size ?
> > >
> > > I already did this here, or something similar at least. Using
> > > a sector_t type that is 64-bit, regardless of platform. Is it
> > > really worth it to differentiate and use 32-bit types for old
> > > machines?
> >
> > Wonderful !
> >
> > I'm not sure how expensive 64-bit arithmetic would be on
> > eg. 386, 486 or 68k machines, or how much impact the extra
> > memory taken would have.
> >
> > OTOH, I'm not sure what problems it could give to make this
> > a compile-time option...
>
> Plus compile time options are nasty :-). It would probably make
> bigger sense to completely skip all the merging etc for low end
> machines. I think they already do this for embedded kernels (ie
> removing ll_rw_blk.c and elevator.c). That avoids most of the
> 64-bit arithmetic anyway.

My 386/486 and m68k-machines with 4/8/16 MB's of memory would be happy
for any and all options to remove code only needed by larger machines.
I'm pretty sure none of my 386:en will ever have 2GB of swap, 2GB of
blockdevices or 2TB filesystems...

Of course, for embedded kernels, being able to exclude block-devices
might be an idea. Or?


/David Weinehall
_ _
// David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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