Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!sgi!shinobu!odin!xhead.esd.sgi.com!jsw
From: jsw@xhead.esd.sgi.com (Jeff Weinstein)
Newsgroups: comp.sys.ibm.pc.rt
Subject: Re: shared memory under AOS4.3??
Message-ID: <1990Aug28.012633.28332@odin.corp.sgi.com>
Date: 28 Aug 90 01:26:33 GMT
References: <1990Aug26.231909.6505@athena.mit.edu> <Fj2wsrx1@cs.psu.edu>
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: jsw@xhead.esd.sgi.com (Jeff Weinstein)
Organization: Silicon Graphics Inc.
Lines: 55

In article <Fj2wsrx1@cs.psu.edu>, ehrlich@cs.psu.edu (Dan &) writes:
> In article <1990Aug26.231909.6505@athena.mit.edu>
dyer@arktouros.mit.edu (Steve Dyer) writes:

> Steve> Has anyone out there hacked up an implementation of
> Steve> one sort or another of shared memory for AOS4.3?
> Steve> I've got this suite to port to AOS4.3 which expects
> Steve> that the applications are sharing several variables in
> Steve> main memory.  Before I decide to eviscerate and
> Steve> redesign the code, I thought I'd see if there was
> Steve> a quicker way out.
>
> Somehow Xtrek running on RTs under AOS fakes shared memory.  Not sure how it
> does this, but I assume that a cruise through the code would reveal the
> secrets.

	Oh no, a gross hack from my past comes back to haunt me...  :-)

	The code in xtrek to do shared memory uses a little known hack
	in the kernel to support X10 on the IBM AED display.  The AED did
	not have a host addressable frame buffer, so to make X10 work some
	guys at Brown faked it(you guys out there?).  The kernel creates 
	an area of memory the same size as the AED frame buffer and maps it 
	read/write into	every process.  The X server then draws into this 
	fake frame buffer.  Once the X server is done drawing it does an 
	ioctl that tells the kernel to copy a region from the fake frame 
	buffer to the real graphics board by sending it down the AED 
	graphics FIFO.

	When I ported X11 to the AED I did a real device port, rather
	than use mfb code and fake buffer.  This resulted in much better
	performance.  Then one day I got a copy of xtrek.  I wanted to
	port xtrek to X11, but couldn't run it on our machines since we
	didn't have shared memory.  My solution was to use the AED fake
	frame buffer, since it was mapped read/write by all processes.
	Once that was resolved I went on to port xtrek to X11.

	I believe that the current AOS kernel only enables this fake
	buffer if certain options are enabled in your config file.
	One option was X10, and another was specifically for xtrek, but
	obtusely named, so at to not upset management, etc.  Perhaps
	Bill Webb would like to comment?  The code is in machdep.c, and
	is surrounded by #if defined(X10) || defined(XsomethingIDontRemember).

	Hope this helps you steve.  It is by no means a real/robust
	solution, but it can be used for hack code.  For more info
	you should check out the version of xtrek shipped on the
	X11R3 contrib tape.  If you can't find it let me know.

		--Jeff

Jeff Weinstein - X Protocol Police
Silicon Graphics, Inc., Entry Systems Division, Window Systems
jsw@xhead.esd.sgi.com
Any opinions expressed above are mine, not sgi's.