From owner-freebsd-hackers Tue Nov 7 21:46:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA23628 for hackers-outgoing; Tue, 7 Nov 1995 21:46:01 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA23623 for ; Tue, 7 Nov 1995 21:45:59 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id WAA19287; Tue, 7 Nov 1995 22:42:30 -0700 From: Terry Lambert Message-Id: <199511080542.WAA19287@phaeton.artisoft.com> Subject: Re: ideas from netbsd To: nate@rocky.sri.MT.net (Nate Williams) Date: Tue, 7 Nov 1995 22:42:30 -0700 (MST) Cc: terry@lambert.org, nate@rocky.sri.MT.net, hackers@FreeBSD.org In-Reply-To: <199511080532.WAA27944@rocky.sri.MT.net> from "Nate Williams" at Nov 7, 95 10:32:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2006 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > > The VM86() patches aren't up to date with respect to the NetBSD kernel, > > > let alone the FreeBSD kernel AFAIK. I've got the VM86() patches and the > > > NetBSD tree which they patched against stored away somewhere, but when I > > > attempted to roll the patches in FreeBSD the x86 code in FreeBSD and > > > NetBSD are so *radically* different that it wasn't going to happen. > > > > Yah. I saw a lot of differences in the page table stuff. It was > > annoying; I didn't see any real reason for the change in FreeBSD in > > that area since about May (or June?). > > There weren't any changes made. When the 4.4Lite -> FreeBSD 2.X diffs > were made the x86 trees were radically different already, so the > problems weren't 'added' recently. The differences in how we do x86 > stuff goes way back. Jack Vogel's SMP patches did not apply cleanly to -current without a lot of work, in part because of the locore.s changes since June. > > The biggest problem was duplicate rather than inline code for the > > debugger support. I guess this is a problem in having it possible > > to disable the kernel pieces. I think the space savings are a > > false economy that end up costing more in the long run in needing > > multiple maintainers. Not to mention kernel rebuilds to get features > > that shouldn't be switched at compile time anyway. 8-(. > > Huh? Check the VM86() patches vs. the kernel debugger support. If you hand apply the patches, they work, but only if you don't build with debugging or profiling of the kernel enabled. Like Jack Vogel's SMP patches. > > I don't know how closely their -current echoes their intended Nov 17th > > release code base... maybe not very closely at all. > > Commits aren't made to the code base. The release code is in a separate > branch, so commits made won't necessarily be in the release tree. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.