Subject: Re: The demise of DEV_BSIZE
To: None <firstname.lastname@example.org, email@example.com>
From: Ross Harvey <firstname.lastname@example.org>
Date: 10/06/1999 12:40:15
Can someone propose a possible application for sector size != 2**n?
The previous mention of "audio CD's" was just someone's mistake. Audio
CD's don't really have sectors or blocks. Yes, there is 2352 bytes of CDDA
and subchannel data combined with ECC and control collections of 784 and
98 bytes. However, these "sectors" cannot be reliably addressed individually;
the fundamental CD-DA structure is a frame of 588 channel bits to support
192 CD-DA bits. It supports approximate positioning via the q-bit subchannel.
However, this is provided mainly for the mm:ss displays, and on most drives
is not precise.
Organization into sectors with numbers in their headers (like magnetic
disks have) is something that postdates the Red Book CD-DA format, and this
is the data CD, or "CD/ROM Mode 1" that we are interested in. It has
2048-byte sectors that can be individually and reliably read. Note that
"reliable" here refers not just to the extra ECC you get, but more
importantly: the drive can give you exactly the sector you want, rather
than merely restarting the stream at *about* the place you want.
I'm not opposed to sector size != 2**n, but I would like to hear at least
*one* good reason for it. CD-DA doesn't seem to cut it as a reason.
And if we are the only OS to provide such an interface, are there really
likely to be applications for it? Conversely, if other kernels do not
support it, are such devices ever likely to appear in the future? This
would argue against the "be prepared for the future" argument.
There is, BTW, an obvious compromise for supporting sector size != 2**n
without the test, branch, and icache-thrashing code bloat: you can just
defopt the subfeature and conditionally define dbtob() and btodb() to
compile only the shift by default.