In short, Koji Imada provides 3 different solutions to solve this
problem.

5.1. use physical sector size as abstraction. (PR kern/3790)
5.2. use DEV_BSIZE as abstraction. (PR kern/3791)
5.3. permit any sector size. (PR kern/3792)

>>>>> On Thu, 26 Jun 1997 10:20:24 -0700,
	Jason Thorpe <thorpej@nas.nasa.gov> said:

> I agree with Matt, here... Basically, it's _very_ convenient to assume
> DEV_BSIZE in the rest of the kernel as, basically, an abstraction.

In other words, you like his solution 5.2. (PR kern/3791)
Is this right ?

Hmm... 
I like his solution 5.1. (PR kern/3790), because:
- device driver should provide what the device are.
  It seems somewhat wasteful that all device drivers do blocking and
  deblocking to support DEV_BSIZE abstraction.
  If there are N devices and M real file systems, always N > M.
  (I actually use only 3 real file systems. i.e. ffs, msdosfs, cd9660).
  So, file system layer should deal with various block sizes, not
  device driver layer.
- As showed by his kern/3790, essentially, ffs and msdosfs are already
  able to deal with the filesystems which block size != 512, and
  cd9660 file system's block size != 512.
- kern/3790 is simplest (shortest) one.
And, it seems that fixed (512 bytes) length abstraction is not modern...

> Koji-san has caught the file system cases.  But, what about the swap
> pager?  What about raw i/o?

I think he already provides raw i/o fix, and probably swap pager could 
use d_secsize field of swap device's disklabel.

BTW, Non-512 bytes block devices are very popular in Japan. 
(e.g. 2048 bytes/sector Magneto-Optical disk, 1024 bytes/sector floppy
 disk, 256 bytes/sector HDD, and DVD will be also 2048 bytes/sector).
So, we Japanese are all eagerly looking forward to this fix.

P.S.
I've heard that Koji likes solution 5.3 (kern/3792), :-)
Undoubtedly 5.3 is most flexible solution. (e.g. cd9660fs on HDD).
But I think it could be solved by his vnode disk driver (it provides
sector size conversion).
--
soda