Date: Tue, 13 May 1997 13:59:01 +0200 From: j@ida.interface-business.de (J Wunsch) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Cc: jmz@cabri.obs-besancon.fr Subject: Big problem with b_blkno Message-ID: <19970513135901.QU53254@ida.interface-business.de>
next in thread | raw e-mail | index | archive | help
Extract from physio():
bp->b_blkno = btodb(uio->uio_offset);
This block number is being passed down to the strategy routine of the
block device drivers. No uio_offset itself is being passed down
whatsoever. This is nonsense.
The only acceptable definition of btodb() could be
#define btodb(x) (x)
The actual definition is in /sys/i386/include/param.h, and looks much
more complicated. In particular, it employs a shift operation, and
thus loses potential information from uio_offset, in the (wrong)
assumption that all device drivers operate in DEV_BSIZE units. While
there's no actual loss of information for device drivers that operate
with (2^n) * DEV_BSIZE {n >= 0} as their physical block size, this
loss of information is fatal when it comes to `odd' physical block
sizes, e.g. with CD-ROMs. CD-ROMs can take a number of different
block sizes, depending on the data format. The two most popular block
sizes are 2048 (CD-ROM, not much of a problem), and 2352 (CD-DA, CD
`raw' blocks, big problem).
How to solve this problem? Define btodb() as shown above, and fix up
all block device drivers? This looks like the cleanest way to me.
Are there any other enlightening solutions?
(Jean-Marc, this means the bogus division in wormstart() needs to stay
until the above problem is fixed. Sigh.)
--
J"org Wunsch Unix support engineer
joerg_wunsch@interface-business.de http://www.interface-business.de/~j
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970513135901.QU53254>