🚀 go-pugleaf

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.


--
Dan Ehrlich <ehrlich@cs.psu.edu>/Voice: +1 814 863 1142/FAX: +1 814 865 3176

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.

In article <1990Aug28.012633.28332@odin.corp.sgi.com> jsw@xhead.esd.sgi.com (Jeff Weinstein) writes:
>
>	The code in xtrek to do shared memory uses a little known hack
>	in the kernel to support X10 on the IBM AED display.

Didn't X10 also use shared memory for server<->client communication?

I seem to recall the Brown guys describing their implementation as
"an exercise in avoinding system calls".

---------------------------------------------------------
David Berkowitz   ..!uunet!ibmsupt!david   (415) 855-4485
IBM AWD Palo Alto
Opinions are mine. Who else would want them?

In article <1990Aug28.012633.28332@odin.corp.sgi.com>,
jsw@xhead.esd.sgi.com (Jeff Weinstein) writes:
|> 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:
|> ...
|> 	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).
|> 		--Jeff


Aha, another gross hack come back to haunt me too!

Ok, here are the relevent lines from /sys/ca/machdep.c:

/*
 * Support for AED simulated bitmap hack
 * we include this support if AED is configured and
 * either X10 support is specified or XWM is specified
 * (the latter is only for a single program that uses
 * the bitmap as shared memory and should eventually
 * disappear).
 */
#include "xtenemul.h"
#include "aed.h"
#if (NAED > 0 && NXTENEMUL > 0) || defined(XWM)
#include "../machinecons/apaaed.h"
#endif (NAED > 0 && NXTENEMUL > 0) || defined(XWM)

If it is obvious from the above the kernel option is "XWM". In case
you are wondering XTENEMUL is used instead of X10 because config 
didn't like numbers in option names.

PS: for those wondering how to configure a BSD 4.3 kernel for the
IBM 6152 so that it can run xtrek - XWM is it!

----------------------------------------------------------------
The above views are my own, not necessarily those of my employer.
Bill Webb (IBM AWD Palo Alto), (415) 855-4457.
UUCP: ...!uunet!ibmsupt!webb