Date: Tue, 7 Nov 1995 18:26:42 -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, jkh@time.cdrom.com, hackers@FreeBSD.org Subject: Re: ideas from netbsd Message-ID: <199511080126.SAA18685@phaeton.artisoft.com> In-Reply-To: <199511072108.OAA26736@rocky.sri.MT.net> from "Nate Williams" at Nov 7, 95 02:08:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. > 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? > 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?). 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-(. > 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. I don't know how closely their -current echoes their intended Nov 17th release code base... maybe not very closely at all. If that's the case, then an interested party would have to wait for them to check in the changes. > AFS is a kernel mod, JAVA doesn't (yet) exist and the work done to build > a thread-safe library more easily be done in FreeBSD than trying to do > NetBSD emulation mode. World21 ??? In order: AFS the kernel mod requires a NetBSD kernel emulation environment for at least the "cookie" differences on lookup (COMPAT_NETBSD). 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. World21 is a kernel module that overwrites the console driver for support of ISO2022 and JIS208+212. It was the first third party LKM for NetBSD. It would also require a kernel emulation environment. (COMPAT_NETBSD). 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?199511080126.SAA18685>