Date: Tue, 7 Nov 1995 22:58:04 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@rocky.sri.MT.net (Nate Williams) Cc: terry@lambert.org, nate@rocky.sri.MT.net, hackers@FreeBSD.org Subject: Re: ideas from netbsd Message-ID: <199511080558.WAA19408@phaeton.artisoft.com> In-Reply-To: <199511080551.WAA28024@rocky.sri.MT.net> from "Nate Williams" at Nov 7, 95 10:51:56 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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) Except as testimony to the fact that the changes don't go all the way back to 4.4Lite. > > > > 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 The debugger and profiling support seem to be the larges area of duplicated code, and it's the duplicated code as well as the semantic changes that make the application of the patches unclean. If all you had to do was "do the same stuff, but do it in the new code", then it'd be an easy hack. As it is, it's not an easy hack because of the conditional replacement code that should probably be default but switched in all cases. > I'm *really* tempted to to go fix the darn arp bug I'm seeing, sigh...) Do it! You'll sleep better. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511080558.WAA19408>