dyer@arktouros.mit.edu (Steve Dyer) (08/27/90)
Has anyone out there hacked up an implementation of
one sort or another of shared memory for AOS4.3?
I've got this suite to port to AOS4.3 which expects
that the applications are sharing several variables in
main memory. Before I decide to eviscerate and
redesign the code, I thought I'd see if there was
a quicker way out.
---
Steve Dyer
dyer@ursa-major.spdcc.com aka ...!{harvard,linus,ima,m2c,rayssd}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.eduehrlich@cs.psu.edu (Dan &) (08/27/90)
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 3176jsw@xhead.esd.sgi.com (Jeff Weinstein) (08/28/90)
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.
david@outrigger.awdpa.ibm.com (08/29/90)
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?
webb@ibmpa.awdpa.ibm.com (Bill Webb) (08/30/90)
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