m...@3am-software.com (Matt Thomas) writes:
>> Keeping DEV_SIZE at 512 bytes avoids lots of changes.
>So?
Keeping or changing DEV_BSIZE does nothing for the issue at
hand: support for disks with non-512byte-sectors.
Why would you want to mix a change to DEV_BSIZE for whatever
reason into it?
>My feelings are this: when accessing the device through a bdevsw =
>(d_psize or d_strategy), will refer to daddr_t and will be units of the =
>blocksize of the device.
This is not true for NetBSD. disks are addressed in units
of DEV_BSIZE by all filesystems and the sector sizes are
handled by the disk driver. Even the CD-ROM driver
is no different.
Apparently some people consider this a flaw.
>For block access (aka filesystem) only =
>blocksize that are powers of 2 will supported.
Seeing all the old code that deals with the problem in the
terms of bit-shifts, this is probably true.
>For raw device access, any native blocksize can be used (like 2352 for =
>CD audio).
>The btodb/dbtob macros will need another argument to indicate where the =
>block size is obtained.
I'm not sure wether CDs really translate well into this
scheme. After all, the blocksize isn't necessarily constant
over the medium. Even for the specific hardware that does, we
are only talking about accessing the character special device
from userland and not about a filesystem doing I/O through
the strategy routine.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
