Date: Tue, 7 Nov 1995 14:08:15 -0700 From: Nate Williams <nate@rocky.sri.MT.net> To: Terry Lambert <terry@lambert.org> Cc: nate@rocky.sri.MT.net (Nate Williams), jkh@time.cdrom.com, hackers@FreeBSD.org Subject: Re: ideas from netbsd Message-ID: <199511072108.OAA26736@rocky.sri.MT.net> In-Reply-To: <199511072037.NAA18262@phaeton.artisoft.com> References: <199511071957.MAA26537@rocky.sri.MT.net> <199511072037.NAA18262@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > [ ... "why should we have a 'COMPAT_NETBSD' option" ... ] > > TL> Linux DOSEMU. Other VM86(). > > TL> Why would "general NetBSD user binary emulation" require any kernel > TL> options at all? > JH> This is going to be solved by adding general NetBSD user binary > JH> emulation? Helloooooo Terry!! :) > > NW> Because DOSEMU requires *LOTS* of kernel changes for VM86. No userland > NW> code would work w/out the kernel mods. Also, last time I looked VM86() > NW> support *still* isn't in the release kernel, and I don't know if the > NW> patches still being kept up-to-date. > > So you are agreeing with me... the "Linux DOSEMU. Other VM86()." is > mine. The ""'ed material in my previous post was from Jordan. I was > responding to the implication that "general NetBSD user binary emulation" > doesn't mean the ability to run NetBSD binaries like DOSEMU in Jordan's > opinion. Different definitions of "general". > > 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. > Unless the changes are going to be rolled in as general FreeBSD > features (any takers?). The VM86() changes *can't* be rolled into FreeBSD in any shape or form as they currently stand (or stood as of March). > If the patches aren't in the source tree, then they are definitely > not being kept up to date. That's the problem with patches that > don't go into the source tree. 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. > The NetBSD "thread environment" consists of both CAP's pthreads code > AND a thread safe libc, etc.. 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. > Which means that instead of the one example Jordan cited (AFS) of a > a desirable piece of NetBSD-only code, the tally is up to a minimum > of three: AFS, JAVA, World21. I think the actual number is higher. 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 ??? > To think that FreeBSD cannot benefit from NetBSD ABI support but > NetBSD can benefit from FreeBSD ABI support is Hubris on the part > of the FreeBSD camp. You still haven't convinced me that the amount of work is worth the effort. I think you're trivializing the amount of work necessary to do anything significant, and making what I consider trivial work to be something much more difficult. VM86 == Lots of work libc thread safe == Little work Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511072108.OAA26736>