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 dholl...@netbsd.org
