>>>>> "|" == Jason Thorpe <thorpej@nas.nasa.gov> writes:

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

Right, it is convenient. But i think it will be also good abstraction
to use physical sector size as it's unit. And it may be more efficient 
for device driver implementation(and some file system implementation).

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

Although raw i/o seems to be working on my kernel, I don't noticed
swap pager. I think it will be possible to adopt swap pager to this
change, I will try this(I dislike btodb() and dbtob() like dtom() :-).

Any other problem?

BTW, I think buffer cache needs some re-engineering. I made vnode disk
to be able to vnconfig'd to block device and saw some cache
inconsistency.

#raw device was impossible in current vnode disk driver
#implementation.

 |> I think it's really much more convenient to assume DEV_BSIZE everywhere
 |> and do conversions in the actual drivers.  The conversions are relatively
 |> simple, really.

Simple, but wasteful. When using file system, convert it to DEV_BSIZE
unit in file system code and re-convert it to physical sector size
unit in device driver.

 |> If you take a look in e.g. vndstrategy() (I pick that one because that's
 |> the one I've hacked on most recently :-), there is a check for the transfer
 |> length:

Me too :-). I was working with vnode disk driver to support
disklabel(it was working but more simple and limited, anyway your code
was committed that's good about disklabel ;-<) and physical sector
emulation.

 |> We can always make the assumption that drivers will be given addresses
 |> and lengths in terms of DEV_BSIZE blocks.  lp->d_secsize will _always_
 |> reflect the actual physical sector size.  Values in the disklabel will
 |> _always_ be in terms of physical sector size.  Drivers will _always_
 |> perform sector conversion.

When i send-pr kern/3460, cgd asked me how about the case "physical
sector size != disklabel sector size". It is very interesting case. I
can resolve this problem in device driver. But it was easy to use
modified vnode device driver which can config block device and has
physical sector size emulation.

How about this?

 |> Shouldn't that solve the problem?

I have investigated this case(using DEV_BSIZE unit as interface to
block device driver). In this case(5.2 in my proposal), file system
must support translation. In ufs(ffs), It may be dirty hack or some
amount of re-engineering. Any comments?

Anyway, i want support for 2048 bytes/sector media. I don't care if
fixed DEV_BSIZE will be employed as "current" policy as long as future 
re-engineering is in consideration.
--
Koji Imada - je4owb/2