In article <9404041928.AA00306@icecube.cryogenic.com> billc@iceCuBE.cryogenic.com writes:
> Markus Wild spoketh:
> >Well, although this might sound evil, I'd like to make the serious
> >vote: *don't* go 64bit! This is one of the (few) pets taken over from
> >4.4 that *I* don't want in NetBSD. Now, what are we going to do? I simply
> >don't think voluntarily introducing a MAJOR compatibility drawback to
> >older software (on both the source and binary levels) is a bad thing, more

But Markus, there is no binary compatibility problem.  Yes, there were a
few teething problems within NetBSD itself (it is an alpha release,
after all!), but once those were fixed userland binaries compiled months
ago continue to work just fine.  Yes, a few programs that make bad
assumptions may need source changes before they get rebuilt, but this is
no excuse.  Should NetBSD go to 14-char filenames to preserve
compatibility with programs that made bad V7-based assumptions? I don't
want to be shackled forever to the past.

> >so since this introduction doesn't give us anything new in exchange. Why

It *does* give us things in exchange! 

> >should anyone need 64bit file sizes on a system like the amiga? Why do

I think this is really short-sighted.  Nobody will ever need >4GB files
and disks (remember that off_t effects disk and partition size limits
too!) on the Amiga just like nobody will ever need more than 640K ram,
more that 32M partitions, and just like nobody will ever to use a disk
with more than 1000 cyls. 

4GB+ disks are availible *today*.  There are already people using 2.5GB
disks on the Amiga with NetBSD, maybe even larger.  There is no reason
why they shouldn't be able to use 11GB disks that are availible today
right now.  There are already AmigaDOS users bumping that OS's 4GB
limits too.

Also consider that NetBSD/amiga users might want to mount remote
filesystems and operate on >4GB files there (databases, for example).
I don't see how this can be described as "for nothing", or a future
concern. This is a real issue now.

> >really meant to be a flame, but it probably is..  (BTW: just because it's
> >in 4.4 is no reason for me to not question it...)

This reply isn't meant to be a flame either... but I do think it is an
important issue. Also, I agree that 4.4 isn't the issue. I would be
pushing for 64 bit off_t's even if 4.4 didn't have them :-)

> As an option, this is fine, as a default, I don't think that would be a good  

It can't easily be made an option. 32 bit off_t binaries can run on 64
bit kernels fine, but not vice-versa... also, I think binary
compatibility with other 68k NetBSDs is important.

> idea.  Growing the kernel size, plus making it slower, is not that good of a  

Without any hard numbers on the performance impact, attacking the
feature because it MIGHT be slow is a bad idea...  History has shown
that programmers are completely unreliable in determining performace
impacts of various changes, which is why profiling was born. I would
like to see some benchmarks for 32bit vs 64 bit kernels before any
decision is made. So far, though, I haven't heard anyone on
current-users complain about ay speed losses.

> "benefit".  Since a lot of the machines that we want to eventually support do  
> not have an FPU, this would make it viciously slower (it's bad enough that  

Huh? The FPU isn't used for quad_t's. quad_t's are implemented by gcc as
a pair of longs, not as a double. (although off_t as a double is an
interesting concept... does that mean you could lseek(fd, bitnumber/8.0,
SEEK_SET) for bit adressing of files? :->)

> the current binaries are compiled for the FPU (to the best of my knowledge),  
> which I think shouldn't be since they are the default binaries, but that's my  
> own nit).  Basically, I want to keep the general attitude of "you do with  

Well, in reality virtually every accelerated Amiga with a MMU has an
FPU, so it's not as bad as if NetBSD/i386 required a FPU...

> your own kernel and binaries what you want", but for the default stuff, it  
> should be small, fast, and not require a lot to get it going.  Does this seem  
> too dictatorial?

If it were that easy it might not be too bad, but it's not just
something you can make optional easily... see above. If the default were
32-bit, it would make it almost impossible for people to set up 64-bit
systems. At that point, it'd almost be like two different architectures,
and since disks are getting steadily bigger the change is bound to be
made back to 64 bit sooner or later. Probably sooner.

(come to think of it, isn't of_t signed? That would make the 32 bit limit
2GB, not 4GB...)

-- 
Ty Sarna                 "As you know, Joel, children have always looked
tsarna@endicor.com        up to cowboys as role models. And vice versa."

------------------------------------------------------------------------------