[  The biggest problem is that disks are addressed by sector number, which
[  means that the kernel and the disk have to agree on the sector size for
[  things to work.  For example, a kernel that assumes .5K blocks would
[  expect that reading 1K starting with block 0 returns the same data as
[  reading .5K at block 0 and .5K at block 1; a disk with 1K sectors will
[  return rather different data for the second half-K when accessed thus.

It's too bad we don't have the NeXT kernel sources to examine, because the  
NeXTSTEP kernel sure seems readily able to adjust to the block size on a  
per-device basis.  You can have multiple drives attached and accessible at the  
same time, some with .5K and some with 1K (not to mention 2K CD-ROM, but there  
might be some sleight-of-hand going on there).  I understand what you're  
saying, but the NeXT code does not seem to be hard-coded in this respect.   
However, if the NetBSD code is hard-coded, then it might take a significant  
revision to support varying blocks/sector.

One thing I have not tested is devices with a block size greater than the  
filesystem sector size.  Once upon a time, before CD/R was prevalent, I wanted  
to make a NeXT CD-ROM.  I was told to format a SCSI hard drive with 2K blocks  
and use newfs to create a filesystem with 2K sectors.  Then, it would be easy  
enough to do a block copy from the SCSI drive to a CD.  This is still a block  
size equals sector size setup.  I'm wondering if the NeXT kernel would be happy  
reading a 1K sector filesystem from a 2K block device.  Somehow I really doubt  
it.

Brian Willoughby
Sound Consulting