lkml.org 
[lkml]   [2000]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Large File support and blocks.
On Fri, Sep 01, 2000 at 09:16:23AM -0700, Linda Walsh wrote:
> With all the talk about bugs and slowness on a 386/486/586 -- does anyone
> think those platforms will have multi-T disks hooked up to them?

Propably not.
...
> If you changed all the block number definitions to use 'block_nr_t'
> instead of int *and* if block_nr_t is typedef'ed to be an int,
> then there would be no performance impact and the code would be
> marginally more clear with marginally better type checking.

No. Plain scalar integer variants can't be typechecked very
strictly at all. You can store short to long, and reverse
without getting any complaints from current compilers :-(
( There are ways, at LFS development I used one to create
real strict typechecking within ANSI-C )
...
> Once the above is in place does anyone see a problem if the defines were
> moved into the arch specific includes and made it arch-specific? Does
> gcc have a bug on platforms that have native 64-bit registers?

No/no. Yes. (I am yet to see GCC which is bug free..
Will the bugs harm, that is an other story.)

> Second question -- within the ia32 domain, can it be selectable per/
> CPU type? Like say only for CPU=686 or above?
>
> Third, could it eventually be a compile-time option if desired?

A separate configuration time option more likely.

> Thanks...
> --
> Linda A Walsh | Trust Technology, Core Linux, SGI
> law@sgi.com | Voice: (650) 933-5338

/Matti Aarnio
-
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/

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