From owner-freebsd-hackers  Tue Nov  7 21:49:49 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id VAA23756
          for hackers-outgoing; Tue, 7 Nov 1995 21:49:49 -0800
Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA23751
          for <hackers@FreeBSD.org>; Tue, 7 Nov 1995 21:49:46 -0800
Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id WAA28024; Tue, 7 Nov 1995 22:51:56 -0700
Date: Tue, 7 Nov 1995 22:51:56 -0700
From: Nate Williams <nate@rocky.sri.MT.net>
Message-Id: <199511080551.WAA28024@rocky.sri.MT.net>
To: Terry Lambert <terry@lambert.org>
Cc: nate@rocky.sri.MT.net (Nate Williams), hackers@FreeBSD.org
Subject: Re: ideas from netbsd
In-Reply-To: <199511080542.WAA19287@phaeton.artisoft.com>
References: <199511080532.WAA27944@rocky.sri.MT.net>
	<199511080542.WAA19287@phaeton.artisoft.com>
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

[ NetBSD VM86() patches ]
> > 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.

Those changes are irrelevant to the discussion.  I had problems in
*March* because of the differences in the x86 support, let alone the
differences that both camps have made since then.  (I seem to remember
lots of x86 changes related to emulation made in the low-level stuff)

> > > 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.

Umm, no.  The changes affect much more than the kernel debugger support.
I tried to do a quick and dirty port, but even that wasn't to be.  But,
then again I'm no kernel hacker, and have no desire to be one.  (Though
I'm *really* tempted to to go fix the darn arp bug I'm seeing, sigh...)


Nate