Date: Mon, 2 Dec 1996 12:03:36 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: cracauer@wavehh.hanse.de Cc: msmith@atrad.adelaide.edu.au, Freebsd-ports@freebsd.org Subject: Re: Other ports (Re: FreeBSD/MIPS anybody) Message-ID: <199612020133.MAA02185@genesis.atrad.adelaide.edu.au> In-Reply-To: <9611301104.AA22755@wavehh.hanse.de> from Martin Cracauer at "Nov 30, 96 12:04:30 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Martin Cracauer stands accused of saying: > > >I've been studying the NetBSD code for a little while now, and it > >strikes me just how much of the VM seems to be replicated from one > >architecture to the next. Is this really necessary? How much of > >the FreeBSD VM is actually x86-specific, and how much could > >reasonably be moved out and reused by other architectures? > > Why do you claim netBSD rewrote its VM for each architecture. At least > the parts affecting my bechmarks are quite similar in each :-) Firstly, it's worth noting that whilst I have a basic grip on the principles behind VM implementations, I make no claims about understanding or being able to read implementations 8( My impressions, taken from reading various NetBSD architecture VM bits (most notably arc, pmax and some sun3) was that there was a lot of duplication of functionality in the pmap module. It may also be that, without any decent documentation on what this module is supposed to achieve, that I am failing to notice subtle architecture-specific differences. > NetBSD reorganised major kernel parts several times, causing driver > developers to cry. They claim it is needed to make live for other > platforms easier respectivly port maintainers would start to maintain > their own slightly modified versions of kernel parts, thus leading to > maintainance nightmares. I understand entirely the desire to remove device drivers for non-architecture-specific devices from any architectural association; with NetBSD there are still a lot of drivers that have machine-specific assumptions that haven't been migrated, but I presume this is proceeding. (It was of particular interest to me, as the Mips systems I have are BE VME systems, and it would be nice to instantly win all the sun3 VME drivers.) > If FreeBSD is going to be ported to other architectures, I expect the > need for a lot of reorganization/generalization in the FreeBSD kernel > to arise. Otherwise, other ports than the main (x86) will have a code > base with a full kernel source of their own (as does the SMP kernel > for now). This is a given, and regardless of which additional architecture(s) FreeBSD might be ported to discussion on what shape these changes might take is a primary concern. With the relatively long road to 3.0 ahead of us, now would be an excellent time to contemplate this. In particular, some input from the CVS monsters^H^H^H^H^H^H^Heisters as to the sorts of chaos that this might cause would be useful in colouring the debate. > Martin -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612020133.MAA02185>