Date: Mon, 6 Oct 1997 23:35:17 +1000 From: Bruce Evans <bde@zeta.org.au> To: julian@whistle.com, phk@critter.freebsd.dk Cc: davidg@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, joerg_wunsch@uriah.heep.sax.de Subject: Re: New SCSI Framework Patches Available Message-ID: <199710061335.XAA03686@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>my new disk layer stuff basically works in byte offsets. >it starts with b_blkno, but all comparisins etc. end up being >u_int64_t based.. > >(offset_t?) off_t? Other parts of the system don't even pretend to support offsets >= 2^63. Negative offsets on disks are errors, but negative relative offsets may be useful. >> >> > I would prefer a transition from b_blkno to b_offset, thereby >> >> > eliminating all the ``shift right here, shift back left there'' mess >> >> > completely. >> >> I agree. >me too There is no way to eliminate the shift that converts filesystem blocks to disk blocks or bytes. Currently, this is the only shift invovled in the usual case where the h/w block size == DEV_BSIZE (at least in 2.2; in -current there are several evil multiplications and divisions in sd.c and od.c just to support unusual cases). If offsets were used everywhere, there would be an additional shifts or division to convert from byte offsets to h/w block numbers. >though I'd like to leave the b_pblkno, or maybe make it a b_poffset. I think it should be a block number (in h/w disk block size units) and all checking and conversions of buffer offsets and ranges should be centralized in dscheck(). It doesn't need to be 64 bits yet. I think the (time) bloat for b_offset instead of b_blkno would be less than the current bloat for just one of the evil divisions in sd.c. Not good, but probably acceptable. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710061335.XAA03686>