Permalink
Browse files

#

  • Loading branch information...
1 parent e1a2397 commit 28f934baaed00868003eea0196c5f2fb71807900 @loveshack loveshack committed Oct 3, 1999
Showing with 40,220 additions and 0 deletions.
  1. +2 −0 etc/.cvsignore
  2. +75 −0 etc/3B-MAXMEM
  3. +221 −0 etc/AIX.DUMP
  4. +176 −0 etc/BABYL
  5. +88 −0 etc/CENSORSHIP
  6. +57 −0 etc/CHARSETS
  7. +74 −0 etc/CODINGS
  8. +975 −0 etc/ChangeLog
  9. +143 −0 etc/DEBUG
  10. +642 −0 etc/JOKES
  11. +122 −0 etc/LPF
  12. +144 −0 etc/MH-E-NEWS
  13. +194 −0 etc/MH-E-ONEWS
  14. +6,740 −0 etc/NEWS
  15. +5,710 −0 etc/ONEWS
  16. +1,691 −0 etc/OONEWS
  17. +1,609 −0 etc/OOONEWS
  18. +1,348 −0 etc/OOOONEWS
  19. +1,165 −0 etc/OOOOONEWS
  20. +1,049 −0 etc/OTHER.EMACSES
  21. +2,244 −0 etc/PROBLEMS
  22. +210 −0 etc/SUN-SUPPORT
  23. +229 −0 etc/TERMS
  24. +48 −0 etc/TODO
  25. +1,013 −0 etc/TUTORIAL.cs
  26. +1,443 −0 etc/TUTORIAL.de
  27. +971 −0 etc/TUTORIAL.ja
  28. +978 −0 etc/TUTORIAL.ko
  29. +1,132 −0 etc/TUTORIAL.nl
  30. +1,165 −0 etc/TUTORIAL.pl
  31. +1,111 −0 etc/TUTORIAL.ro
  32. +1,031 −0 etc/TUTORIAL.sl
  33. +1,007 −0 etc/TUTORIAL.th
  34. +244 −0 etc/WHY-FREE
  35. +98 −0 etc/Xkeymap.txt
  36. +819 −0 etc/copying.paper
  37. +1 −0 etc/ctags.1
  38. BIN etc/e/eterm
  39. +21 −0 etc/e/eterm.ti
  40. +207 −0 etc/echo.msg
  41. +858 −0 etc/edt-user.doc
  42. +45 −0 etc/emacs.bash
  43. +25 −0 etc/emacs.csh
  44. +34 −0 etc/emacs.icon
  45. +38 −0 etc/emacs.xbm
  46. +65 −0 etc/emacsclient.1
  47. +225 −0 etc/etags.1
  48. +67 −0 etc/gnu.xpm
  49. +312 −0 etc/ms-7bkermit
  50. +167 −0 etc/ms-kermit
  51. +1 −0 etc/refcard.bit
  52. +653 −0 etc/refcard.tex
  53. +38 −0 etc/ulimit.hack
  54. +681 −0 etc/vipcard.tex
  55. +746 −0 etc/viperCard.tex
  56. +68 −0 man/back.texi
View
@@ -1 +1,3 @@
fns-*
+*.ps
+*.log
View
@@ -0,0 +1,75 @@
+Date: Mon, 16 Feb 87 15:04:41 EST
+From: katinsky@gauss.rutgers.edu (David Katinsky)
+To: rms@prep.ai.mit.edu
+Subject: 3b2 procedure to raise MAXMEM
+
+Below is the procedure I followed to allow enough memory for GnuEmacs to run
+on my 3b2/400. The end result of this is that a process can snarf up to 2Mb
+of memory. This can be a bit dangerous on a 2Mb machine, but I tried it and
+it worked ok.
+
+-------------------------------------------------------------------------------
+
+In the simplest case, these are the procedures to reconfigure a 3bx kernel.
+
+
+
+1] cd /etc/master.d
+
+`ls` shows the files to be:
+
+README ctc* hdelog idisk ipc iuart kernel mau
+mem msg ports* prf sem shm stubs sxt
+sys xt
+
+2] Edit the file which contains the parameter[s] you wish to change.
+In the following excerpt from /etc/master.d/kernel the value MAXMEM
+was raised from 256 to 1024.
+
+In V.3.0 and later releases, the parameter in question is MAXUMEM
+instead of MAXMEM.
+
+
+ *
+ * The following entries form the tunable parameter table.
+ *
+
+
+ NCALL = 30
+ NPROC = 60
+ NTEXT = 58
+ NCLIST = 188
+ * maxmem is number of pages (2K) was 256 --dmk
+ MAXMEM = 1024
+ MAXUP = 25
+ * hashbuf must be a power of 2
+ NHBUF = 128
+ NPBUF = 8
+
+3] cd /boot
+
+4] mkboot -k KERNEL
+
+5] shutdown -i5 -g0 -y
+
+This will take the machine down and bring it back up into firmware
+mode. When you see that the machine has reached this state, type the
+firmware password (default=mcp). The machine will ask for the name of
+a program to execute. At this prompt enter /etc/system . The machine
+should start to boot and display its configuration data.
+
+
+
+8701271222 dmk
+
+ [katinsky@topaz.rutgers.edu]
+-------------------------------------------------------------------------------
+
+
+
+I do not feel that having the default firmware password is a
+problem... but if you wish to edit it out, feel free.
+
+ dmk
+
+
View
@@ -0,0 +1,221 @@
+The following text was written by someone at IBM to describe an older
+version of the code for dumping on AIX. It does NOT apply to
+the current version of Emacs. It is included in case someone
+is curious.
+
+
+I (rms) couldn't understand the code, and I can't fully understand
+this text either. I rewrote the code to use the same basic
+principles, as far as I understood them, but more cleanly. This
+rewritten code does not always work. In fact, the basic method
+seems to be intrinsically flawed.
+
+Since then, someone else implemented a different way of dumping on
+the RS/6000, which does seem to work. None of the following
+applies to the way Emacs now dumps on the 6000. However, the
+current method fails to use shared libraries. Anyone who might be
+interested in trying to resurrect the previous method might still
+find the following information useful.
+
+
+It seems that the IBM dumping code was simply set up to detect when
+the dumped data cannot be used, and in that case to act approximately
+as if CANNOT_DUMP had been defined all along. (This is buried in
+paragraph 1.) It seems simpler just to define CANNOT_DUMP, since
+Emacs is not set up to decide at run time whether there is dumping or
+not, and doing so correctly would be a lot of work.
+
+Note that much of the other information, such as the name and format
+of the dumped data file, has been changed.
+
+
+ --rms
+
+
+
+ A different approach has been taken to implement the
+"dump/load" feature of GNU Emacs for AIX 3.1. Traditionally the
+unexec function creates a new a.out executable file which contains
+preloaded Lisp code. Executing the new a.out file (normally called
+xemacs) provides rapid startup since the standard suite of Lisp code
+is preloaded as part of the executable file.
+
+ AIX 3.1 architecture precludes the use of this technique
+because the dynamic loader cannot guarantee a fixed starting location
+for the process data section. The loader loads all shared library
+data BEFORE process data. When a shared library changes its data
+space, the process initial data section address (_data) will change
+and all global process variables are automatically relocated to new
+addresses. This invalidates the "dumped" Emacs executable which has
+data addresses which are not relocatable and now corrupt. Emacs would
+fail to execute until rebuilt with the new libraries.
+
+ To circumvent the dynamic loader feature of AIX 3.1, the dump process
+has been modified as follows:
+
+ 1) A new executable file is NOT created. Instead, both pure and
+ impure data are saved by the dump function and automatically
+ reloaded during process initialization. If any of the saved data
+ is unavailable or invalid, loadup.el will be automatically loaded.
+
+ 2) Pure data is defined as a shared memory segment and attached
+ automatically as read-only data during initialization. This
+ allows the pure data to be a shared resource among all Emacs
+ processes. The shared memory segment size is PURESIZE bytes.
+ If the shared memory segment is unavailable or invalid, a new
+ shared memory segment is created and the impure data save file
+ is destroyed, forcing loadup.el to be reloaded.
+
+ 3) The ipc key used to create and access Emacs shared memory is
+ SHMKEY and can be overridden by the environment symbol EMACSSHMKEY.
+ Only one ipc key is allowed per system. The environment symbol
+ is provided in case the default ipc key has already been used.
+
+ 4) Impure data is written to the ../bin/.emacs.data file by the
+ dump function. This file contains the process' impure data
+ at the moment of load completion. During Emacs initialization,
+ the process' data section is expanded and overwritten
+ with the .emacs.data file contents.
+
+ The following are software notes concerning the GNU Emacs dump function under AIX 3.1:
+
+ 1) All of the new dump/load code is activated by the #ifdef SHMKEY
+ conditional.
+
+ 2) The automatic loading of loadup.el does NOT cause the dump function
+ to be performed. Therefore once the pure/impure data is discarded,
+ someone must remake Emacs to create the saved data files. This
+ should only be necessary when Emacs is first installed or whenever
+ AIX is upgraded.
+
+ 3) Emacs will exit with an error if executed in a non-X environment
+ and the dump function was performed within a X window. Therefore
+ the dump function should always be performed in a non-X
+ environment unless the X environment will ALWAYS be available.
+
+ 4) Emacs only maintains the lower 24 bits of any data address. The
+ remaining upper 8 bits are reset by the XPNTR macro whenever any
+ Lisp object is referenced. This poses a serious problem because
+ pure data is stored in segment 3 (shared memory) and impure data
+ is stored in segment 2 (data). To reset the upper 8 address bits
+ correctly, XPNTR must guess as to which type of data is represented
+ by the lower 24 address bits. The technique chosen is based upon
+ the fact that pure data offsets in segment 3 range from
+ 0 -> PURESIZE-1, which are relatively small offsets. Impure data
+ offsets in segment 2 are relatively large (> 0x40000) because they
+ must follow all shared library data. Therefore XPNTR adds segment
+ 3 to each data offset which is small (below PURESIZE) and adds
+ segment 2 to all other offsets. This algorithm will remain valid
+ as long as a) pure data size remains relatively small and b) process
+ data is loaded after shared library data.
+
+ To eliminate this guessing game, Emacs must preserve the 32-bit
+ address and add additional data object overhead for the object type
+ and garbage collection mark bit.
+
+ 5) The data section written to .emacs.data is divided into three
+ areas as shown below. The file header contains four character
+ pointers which are used during automatic data loading. The file's
+ contents will only be used if the first three addresses match
+ their counterparts in the current process. The fourth address is
+ the new data segment address required to hold all of the preloaded
+ data.
+
+
+ .emacs.data file format
+
+ +---------------------------------------+ \
+ | address of _data | \
+ +---------------------------------------+ \
+ | address of _end | \
+ +---------------------------------------+ file header
+ | address of initial sbrk(0) | /
+ +---------------------------------------+ /
+ | address of final sbrk(0) | /
+ +---------------------------------------+ /
+ \ \
+ \ \
+ all data to be loaded from
+ _data to _end
+ \ \
+ \ \
+ +---------------------------------------+
+ \ \
+ \ \
+ all data to be loaded from
+ initial to final sbrk(0)
+ \ \
+ +---------------------------------------+
+
+
+ Sections two and three contain the preloaded data which is
+ restored at locations _data and initial sbrk(0) respectively.
+
+ The reason two separate sections are needed is that process
+ initialization allocates data (via malloc) prior to main()
+ being called. Therefore _end is several kbytes lower than
+ the address returned by an initial sbrk(0). This creates a
+ hole in the process data space and malloc will abort if this
+ region is overwritten during the load function.
+
+ One further complication with the malloc'd space is that it
+ is partially empty and must be "consumed" so that data space
+ malloc'd in the future is not assigned to this region. The malloc
+ function distributed with Emacs anticipates this problem but the
+ AIX 3.1 version does not. Therefore, repeated malloc calls are
+ needed to exhaust this initial malloc space. How do you know
+ when malloc has exhausted its free memory? You don't! So the
+ code must repeatedly call malloc for each buffer size and
+ detect when a new memory page has been allocated. Once the new
+ memory page is allocated, you can calculate the number of free
+ buffers in that page and request exactly that many more. Future
+ malloc requests will now be added at the top of a new memory page.
+
+ One final point - the initial sbrk(0) is the value of sbrk(0)
+ after all of the above malloc hacking has been performed.
+
+
+ The following Emacs dump/load issues need to be addressed:
+
+ 1) Loadup.el exits with an error message because the xemacs and
+ emacs-xxx files are not created during the dump function.
+
+ Loadup.el should be changed to check for the new .emacs.data
+ file.
+
+ 2) Dump will only support one .emacs.data file for the entire
+ system. This precludes the ability to allow each user to
+ define his/her own "dumped" Emacs.
+
+ Add an environment symbol to override the default .emacs.data
+ path.
+
+ 3) An error message "error in init file" is displayed out of
+ startup.el when the dumped Emacs is invoked by a non-root user.
+ Although all of the preloaded Lisp code is present, the important
+ purify-flag has not been set back to Qnil - precluding the
+ loading of any further Lisp code until the flag is manually
+ reset.
+
+ The problem appears to be an access violation which will go
+ away if the read-write access modes to all of the files are
+ changed to rw-.
+
+ 4) In general, all file access modes should be changed from
+ rw-r--r-- to rw-rw-rw-. They are currently setup to match
+ standard AIX access modes.
+
+ 5) The dump function is not invoked when the automatic load of
+ loadup.el is performed.
+
+ Perhaps the command arguments array should be expanded with
+ "dump" added to force an automatic dump.
+
+ 6) The automatic initialization function alloc_shm will delete
+ the shared memory segment and .emacs.data file if the "dump"
+ command argument is found in ANY argument position. The
+ dump function will only take place in loadup.el if "dump"
+ is the third or fourth command argument.
+
+ Change alloc_shm to live by loadup.el rules.
+
Oops, something went wrong.

0 comments on commit 28f934b

Please sign in to comment.