Date: Tue, 7 Nov 1995 22:32:00 -0700 From: Nate Williams <nate@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 Message-ID: <199511080532.WAA27944@rocky.sri.MT.net> In-Reply-To: <199511080126.SAA18685@phaeton.artisoft.com> References: <199511072108.OAA26736@rocky.sri.MT.net> <199511080126.SAA18685@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > > > I think it's valid to consider the "*LOTS* of kernel changes for VM86" > > > as a candidate for "options COMPAT_NETBSD" (the original point of > > > discussion in this thread being "should we have a COMPAT_NETBSD?"). > > > > Ahh, but this is different than adding some simple 'COMPAT_NETBSD' > > options. You are asking for a complete re-write of the low-level i86 > > handling code, and this can't be done 'simply' by adding a couple ifdefs > > here and there. > > Well, the real point is, why the hell would anyone #ifdef it if they > did the work, since they'd only be diking out stuff that's useful in > general, not just for NetBSD emulation. Correct. Getting the stuff working in *any* shape is mondo-work. > > The VM86() changes *can't* be rolled into FreeBSD in any shape or form > > as they currently stand (or stood as of March). > > They didn't operate as of when they were created? They were created for NetBSD, which does it's x86 *completely* different from the way FreeBSD does it. And, the VM86() mods have not been kept up to date and are not in the NetBSD kernel as far as I know. > > 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. > 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? > > Umm, NetBSD's library is *NOT* thread safe at this stage of the game. > > I watch the commit list, an no thread changes have been made to the > > library in the last 5 months. > > I've been talking once or twice (ie: not in good contact) with the > JAVA porter for NetBSD, and he indicated changes had been made. Nothing was mentioned in the source commits. This isn't to say they haven't been done, but the commit messages haven't lead me to believe those changes have been made. As a matter of fact, *very* few changes have been made to the generic libraries. > 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. > Building a FreeBSD thread-safe library instead of using the NetBSD > effort toget JAVA running (they also heavily modified JAVA to *use* > a user space threads, BTW) seems like NIH. Jordan already pointed this out, but FreeBSD needs a thread safe library for it's own use aside from Java. And, we can grab the modified JAVA code once they've got it working in any case. :) Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511080532.WAA27944>