Date: Tue, 17 Dec 2002 10:18:00 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: phk@FreeBSD.ORG, "M. Warner Losh" <imp@bsdimp.com>, julian@elischer.org, nate@root.org, julian@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/i386 dump_machdep.c Message-ID: <200212171818.gBHII0uf086115@apollo.backplane.com> References: <15358.1040112341@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
I think using off_t is just fine. In fact, I prefer it. As long
as they have sufficient range, signed (64 bit in this case) integers
are always easier to deal with then unsigned integers and it also gives
us a built-in error space.
We had a big long thread about this last year and I think in the end
everyone agreed that going to 64 bit byte offsets in the I/O subsystem
was preferable to 64 bit block numbers. I have always hated the stupid
back-and-forth block<->byte conversions we had (and still have)
strewn around the codebase.
-Matt
Matthew Dillon
<dillon@backplane.com>
:In message <20021216.212401.38686246.imp@bsdimp.com>, "M. Warner Losh" writes:
:>In message: <200212170108.gBH18V4r082434@apollo.backplane.com>
:> Matthew Dillon <dillon@apollo.backplane.com> writes:
:>: Isn't it using off_t there? 64 bit offsets?
:>
:>daddr_t you mean? off_t is for file offsets, not for disklabel
:>sizes...
:
:GEOM operates on byte offsets in order to be able to accomodate non 2^n
:sector sizes (CD's for instance).
:
:Rather than hardcode the size as uint64_t, and rather than introduce
:yet a bloody typedef, I chose to use off_t for the offsets.
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:phk@FreeBSD.ORG | TCP/IP since RFC 956
:FreeBSD committer | BSD since 4.3-tahoe
:Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200212171818.gBHII0uf086115>