Date: Tue, 7 Nov 1995 13:37:03 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@rocky.sri.MT.net (Nate Williams) Cc: terry@lambert.org, jkh@time.cdrom.com, graichen@sirius.physik.fu-berlin.de, hackers@FreeBSD.org Subject: Re: ideas from netbsd Message-ID: <199511072037.NAA18262@phaeton.artisoft.com> In-Reply-To: <199511071957.MAA26537@rocky.sri.MT.net> from "Nate Williams" at Nov 7, 95 12:57:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... "why should we have a 'COMPAT_NETBSD' option" ... ] TL> Linux DOSEMU. Other VM86(). JH> This is going to be solved by adding general NetBSD user binary JH> emulation? Helloooooo Terry!! :) TL> Why would "general NetBSD user binary emulation" require any kernel TL> options at all? 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?"). Unless the changes are going to be rolled in as general FreeBSD features (any takers?). 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. > > If you don't want kernel examples (ie: AFS was a bad example), then > > what about NetBSD's thread environment for their JAVA port? > > What thread environment? You mean CAP's, which is also available for > FreeBSD? The NetBSD "thread environment" consists of both CAP's pthreads code AND a thread safe libc, etc.. Having CAP's code is not sufficient to use the Alpha release of the NetBSD Java port on FreeBSD, except as a statically linked foreign binary. 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. 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. 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?199511072037.NAA18262>