Re: blocksizes

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Jan 24, 2010 at 11:21:52PM +0100, Michael van Elst wrote:
 > > > Not using DEV_BSIZE requires to change how things work now.
 > > 
 > > He is right in the long run, though.
 > 
 > You may think that the way NetBSD works is "a hack" as Izumi Tsutsui
 > put it. But the argument that keeping things they way they are suddenly
 > makes them too simple is just nonsense.

Enh. Design decisions should be made while looking ahead, not with the
nose to the grindstone. What's the right way to do all this? That has
to be established first, then we can debate the merits of how to get
there or of compromises that need to be made with the way things
currently work.

Choosing code architectures because they're easy or apparently simple
(== require less immediate work) is a good way to get into a hole. I
had a coworker once who did a lot of this. His project eventually
needed the equivalent of a federal bank bailout. :-)

In this case, the problem with the way things are is that the way
things are does not work.

I would suggest, based on prior experience with large rototills, that
the symbol DEV_BSIZE be removed entirely and all uses examined one by
one and changed to something else based on the usage. If we want a
symbol that fills the role DEV_BSIZE is maybe supposed to (an
arbitrarily-sized block whose size happens to be convenient for
various legacy reasons) we should call it something else, and make
sure it's only deployed in places where it's correct.

grep shows 718 references in the kernel, so this can't be done all in
one pass, but it's a much smaller problem than e.g. the device/softc
thing.

-- 
David A. Holland
dholland%netbsd.org@localhost