From owner-freebsd-hackers Sat Nov 8 03:13:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA01254 for hackers-outgoing; Sat, 8 Nov 1997 03:13:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA01245 for ; Sat, 8 Nov 1997 03:13:35 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id DAA21113; Sat, 8 Nov 1997 03:13:25 -0800 (PST) Message-ID: <19971108031324.33689@micron.mini.net> Date: Sat, 8 Nov 1997 03:13:25 -0800 From: Jonathan Mini To: Mike Smith Cc: hackers@FreeBSD.ORG Subject: Re: x86 gods; advice? Suggestions? References: <19971108024958.28488@micron.mini.net> <199711081051.VAA00966@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <199711081051.VAA00966@word.smith.net.au>; from Mike Smith on Sat, Nov 08, 1997 at 09:21:50PM +1030 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Smith stands accused of saying: > > > Two possible solutions; use a coprocess running the vm86 thread as a > > > sort of "graphics processor" (involves a context switch between > > > operations, but you could stack them), or wait for the vm86 sysarch() > > > stuff that comes with the vm86 stuff I am working on. (Kernel entry > > > and two context switches per call.) > > > > That is how I originally planned writing the code. I am working on a method > > that uses vfork(2) to see if it is any faster/slower/doesn't-make-a-difference. > > Don't use vfork; it sucks. Use popen() and a dedicated graphics > processor process. Ok. You win. :) > Note that the FreeBSD pipe code has some odd behavioural quirks; most > particularly the more you can write in a single hit, the faster it is. > This is especially the case if you are writing a large amount of data > in a stream between processes. If you're writing from scattered > buffers, using writev() is an *enormous* win. This behaviour is not quirky at all. It makes perfect sense. > > Not much is really done in the vm86 task, just calls to do things like set the > > video mode and such. > > "And such" doesn't include anything particularly speed critical? Nope. "and such" is things like 'please return the video card back to a state that syscons wants it in' -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."