From owner-freebsd-hackers  Sat Nov  8 02:56:06 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA00676
          for hackers-outgoing; Sat, 8 Nov 1997 02:56:06 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (ppp13.portal.net.au [202.12.71.113])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA00646
          for <hackers@FreeBSD.ORG>; Sat, 8 Nov 1997 02:55:59 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost [127.0.0.1])
	by word.smith.net.au (8.8.7/8.8.5) with ESMTP id VAA00966;
	Sat, 8 Nov 1997 21:21:53 +1030 (CST)
Message-Id: <199711081051.VAA00966@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Jonathan Mini <mini@d198-232.uoregon.edu>
cc: Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG
Subject: Re: x86 gods; advice? Suggestions? 
In-reply-to: Your message of "Sat, 08 Nov 1997 02:49:58 -0800."
             <19971108024958.28488@micron.mini.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 08 Nov 1997 21:21:50 +1030
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > 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.

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.

> 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?

mike