On Mon, Jan 25, 2010 at 08:06:11AM +0000, Michael van Elst wrote: > >C hoosing code architectures > > 'Redesigning' things to fix bugs seems to be common sense > nowadays, as if everything existing is always too bad to be > used. > > Of course the same is valid for the redesigned code base in > the future.
Yes, and after a dozen or so such ground-up rebuilds (provided each one is informed by the lessons learned in the previous ones) things start to reach a decent state. > One interesting point is that dropping DEV_BSIZE doesn't > really mean something new but a jump backwards. That's where > we came from, that's what was 'redesigned' then. But as you may have noticed, I'm not advocating going back to using random mixtures of block sizes. > >In this case, the problem with the way things are is that the way > >things are does not work. > > It works fine for 16 years now. The problems only come from legacy > code and code from other sources that wasn't adapted to the then > valid design, mainly because the problems didn't show up immediately > due to lack of hardware. ...that is, it works except when it doesn't. :-P > The software that needs to be fixed is pretty obvious, it's > not a large rototill but if you are into 'redesigning' you > may see a lot of places (unrelated to DEV_BSIZE) that could > be structured better and cleaned up, e.g. partition handling. > > And all this should be done, wether you intend to drop or > keep DEV_BSIZE. Of course... -- David A. Holland dholl...@netbsd.org