The new grub manual is made official.

2001-02-07 20:26:29 +00:00 · 2001-02-07 20:26:29 +00:00 · d20f9609ce
commit d20f9609ce
parent cf58c5c2a9
12 changed files with 4009 additions and 8517 deletions
--- a/13
+++ b/13
@ -1,3 +1,16 @@
 2001-02-08  OKUJI Yoshinori  <okuji@gnu.org>
 	* docs/grub-new.texi: Moved to ...
 	* docs/grub.texi: ... here. And, include internals.texi.
 	* docs/internals.texi: New file.
 	* docs/prog-ref.texi: Removed.
 	* docs/user-ref.texi: Likewise.
 	* docs/tutorial.texi: Likewise.
 	* docs/appendices.texi: Likewise.
 	* docs/Makefile.am (grub_TEXINFOS): Removed prog-ref.texi,
 	user-ref.texi, tutorial.texi, and appendices.texi. Added
 	internals.texi.
 2001-02-03  OKUJI Yoshinori  <okuji@gnu.org>
 	From Erik Schoenfelder <schoenfr@gaertner.de>:
--- a/docs/Makefile.am
+++ b/docs/Makefile.am
@ -1,6 +1,5 @@
 info_TEXINFOS = grub.texi multiboot.texi
-grub_TEXINFOS = tutorial.texi user-ref.texi prog-ref.texi \
+grub_TEXINFOS = internals.texi
 	appendices.texi
 EXAMPLES = boot.S kernel.c multiboot.h
 multiboot_TEXINFOS = boot.S.texi kernel.c.texi multiboot.h.texi
 man_MANS = grub.8 mbchk.1 grub-install.8 grub-md5-crypt.8
--- a/docs/Makefile.in
+++ b/docs/Makefile.in
@ -88,9 +88,7 @@ install_sh = @install_sh@
 info_TEXINFOS = grub.texi multiboot.texi
-grub_TEXINFOS = tutorial.texi user-ref.texi prog-ref.texi \
+grub_TEXINFOS = internals.texi
 	appendices.texi
 EXAMPLES = boot.S kernel.c multiboot.h
 multiboot_TEXINFOS = boot.S.texi kernel.c.texi multiboot.h.texi
 man_MANS = grub.8 mbchk.1 grub-install.8 grub-md5-crypt.8
--- a/docs/appendices.texi
+++ b/docs/appendices.texi
@ -1,324 +0,0 @@
@node FAQ
@appendix Frequently asked questions
@table @asis
@item How does GNU GRUB differ from Erich's original GRUB?
 GNU GRUB is the successor of Erich's great GRUB. He couldn't work on
 GRUB because of some other tasks, so the current maintainers OKUJI
 Yoshinori and Gordon Matzigkeit took over the maintainership, and opened
 the development in order for everybody to participate it.
 Technically speaking, GNU GRUB has many features that are not seen in
 the original GRUB. For example, GNU GRUB can be installed on UNIX-like
 operating system (such as GNU/Hurd) via the grub shell
@file{/sbin/grub} (or @file{/usr/sbin/grub} on older systems), it
 supports Logical Block Address (LBA) mode that solves the 1024 cylinders
 problem, and @kbd{@key{TAB}} completes a filename when it's unique. Of
 course, many bug fixes are done as well, so it is recommended to use GNU
 GRUB.
@item Can GRUB boot my operating system from over 8GB hard disks?
 That depends on your BIOS and your operating system. You must make
 sure that your drive is accessible in LBA mode. Generally, that is
 configurable in BIOS setting utility. Read the manual for your BIOS
 for more information.
 Furthermore, some operating systems (i.e. DOS) cannot access any large
 disk, so the problem is not solved by any kind of boot loader. GNU/Hurd
 and GNU/Linux can surely boot from such a large disk.
@item Can I put Stage2 into a partition which is over 1024 cylinders?
 Yes, if your BIOS supports the LBA mode.
@item How to create a GRUB boot floppy with the menu interface?
 The easiest way is:
@enumerate
@item
 Create filesystem in your floppy disk. For example:
@example
 $ mke2fs /dev/fd0
@end example
@item
 Mount it on somewhere, say, @file{/mnt}.
@item
 Copy the GRUB images to @file{/mnt/boot/grub}. Only @file{stage1},
@file{stage2} and @file{menu.lst} are necessary. You may not copy
@dfn{stage1.5}s.
@item
 Run the following command (substitute @file{/usr/sbin/grub} for
@file{/sbin/grub} if you are using an older system):
@example
@group
 $ /sbin/grub --batch <<EOT
 root (fd0)
 setup (fd0)
 quit
 EOT
@end group
@end example
@end enumerate
@item How to specify a partition?
@xref{Device syntax}.
@item GRUB does not recognize my GNU/Hurd partition.
 I don't know why, but the authors of FDISK programs have assigned the
 partition type @samp{0x63} to GNU Hurd incorrectly. A partition type
 should mean what format is used in the partition, such as filesystem and
 BSD slices, and should not be used to represent what operating system
 owns the partition. So use @samp{0x83} if the partition contains ext2fs
 filesystem, and use @samp{0xA5} if the partition contains ffs
 filesystem, whether the partition owner is Hurd or not. We will use
@samp{0x63} for GNU Hurd filesystem that has not been implemented yet.
@item I've installed a recent version of binutils, but GRUB still crashes.
 Please check for the version of your binutils by this command:
@example
 $ ld -v
@end example
 This will show two versions, but only the latter is important. If the
 version is identical with what you have installed, the installation was
 not bad.
 Well, please try:
@example
 $ gcc -Wl,-v 2>&1 | grep "GNU ld"
@end example
 If this is not identical with the result above, you should specify the
 directory where you have installed binutils for the script configure,
 like this:
@example
 $ ./configure --with-binutils=/usr/local/bin
@end example
 If you follow the instructions above but GRUB still crashes, probably
 there is a serious bug in GRUB. @xref{Reporting bugs}.
@item GRUB hangs up when accessing my SCSI disk.
 Check if you have turned on the support for INT 13 extension (LBA). If
 so, disable the support and see if GRUB can now access your SCSI
 disk. This will make it clear that your SCSI BIOS sucks.
 For now, we know the following doesn't provide working LBA mode:
@table @asis
@item
 Adaptec AIC-7880
@end table
 In the case where you have such a SCSI controller unfortunately, you
 cannot use the LBA mode, though GRUB still works fine in the CHS mode
 (so the well-known 1024 cylinders problem comes again to you).
@strong{Caution:} Actually it has not been verified yet if this bug is
 due to the SCSI BIOS or GRUB itself, frankly speaking. Because the
 developers haven't seen it by their own eyes. This is why it is
 desirable that you investigate the cause seriously if you have the
 skill.
@item How can I specify an arbitrary memory size to Linux?
 Pass a @samp{mem=} option to your Linux kernel, like this:
@example
 grub> kernel /vmlinuz mem=128M
@end example
 You may pass other options in the same way. See @xref{GNU/Linux}, for
 more details.
@item I have a separate boot partition and GRUB doesn't recognize it.
 This is often reported as a @dfn{bug}, but this is not a bug
 really. This is a feature.
 Because GRUB is a boot loader and it normally runs under no operating
 system, it doesn't know where a partition is mounted under your
 operating systems. So, if you have the partition @file{/boot} and you
 install GRUB images into the directory @file{/boot/grub}, GRUB
 recognizes that the images lies under the directory @file{/grub} but not
@file{/boot/grub}. That's fine, since there is no guarantee that all of
 your operating systems mount the same partition as @file{/boot}.
 There are several solutions for this situation.
@enumerate
@item
 Install GRUB into the directory @file{/boot/boot/grub} instead of
@file{/boot/grub}. This may sound ugly but should work fine.
@item
 Create a symbolic link before installing GRUB, like @samp{cd /boot && ln
 -s . boot}. This works only if the filesystem of the boot partition
 supports symbolic links and GRUB supports the feature as well.
@item
 Install GRUB with the command @command{install}, to specify the paths of
 GRUB images explicitly. Here is an example:
@example
@group
 grub> root (hd0,1)
 grub> install /grub/stage1 d (hd0) /grub/stage2 p /grub/menu.lst
@end group
@end example
@end enumerate
@item How to uninstall GRUB from my hard disk drive?
 There is no concept @dfn{uninstall} in boot loaders, because if you
@dfn{uninstall} a boot loader, an unbootable machine would simply
 remain. So all you need to do is overwrite another boot loader you like
 to your disk, that is, install the boot loader without uninstalling
 GRUB.
 For example, if you want to install the boot loader for Windows, just
 run @code{FDISK /MBR} on Windows. If you want to install LILO@footnote{I
 can't imagine why you want to do such a thing, though}, run
@code{/sbin/lilo} on GNU/Linux.
@item GRUB hangs when accessing my large IDE disk.
 If your disk is bigger than 32GB, probably updating your mainboard BIOS
 will solve your problem. This bug is well-known and most vendors should
 provide fixed versions. For example, if you have ASUS-P3BF, upgrading
 the BIOS to V1007beta1 or later can fix it. Please ask your vendor, for
 more information.
@item Why don't Linux, FreeBSD, NetBSD, etc. become Multiboot-compliant?
 Please ask the relevant maintainers. If all free kernels were
 Multiboot-compliant (@pxref{Top, Multiboot Specification, Motivation,
 multiboot, The Multiboot Specification}), the world would be an
 utopia@dots{}
@end table
@node Obtaining and Building GRUB
@appendix How to obtain and build GRUB
@quotation
@strong{Caution:} GRUB requires binutils-2.9.1.0.23 or later because the
 GNU assembler has been changed so that it can produce real 16bits
 machine code between 2.9.1 and 2.9.1.0.x. See
@url{http://sourceware.cygnus.com/binutils/}, to obtain information on
 how to get the latest version.
@end quotation
@c Do not change alpha.gnu.org:/gnu/grub to the URI, since TeX does
@c not format it well.
 GRUB is available from the GNU alpha archive site
@url{alpha.gnu.org:/gnu/grub} or any of its mirrors. The file
 will be named grub-version.tar.gz. The current version is
@value{VERSION}, so the file you should grab is:
@url{ftp://alpha.gnu.org/gnu/grub/grub-@value{VERSION}.tar.gz}
 To unbundle GRUB use the instruction:
@example
 zcat grub-@value{VERSION}.tar.gz | tar xvf -
@end example
 which will create a directory called @file{grub-@value{VERSION}} with
 all the sources. You can look at the file @file{INSTALL} for detailed
 instructions on how to build and install GRUB, but you should be able to
 just do:
@example
@group
 $ cd grub-@value{VERSION}
 $ ./configure
 $ make install
@end group
@end example
 This will install the grub shell @file{grub} (@pxref{Invoking the grub
 shell}), the Multiboot checker @file{mbchk} (@pxref{Invoking mbchk}),
 and the GRUB images It will also install the GRUB manual.
 Also, the latest version is available from the CVS. The repository is:
@code{:pserver:anoncvs@@subversions.gnu.org:/home/cvs}
 and the module is:
@code{grub}
 The password for anoncvs is empty. So the instruction is:
@example
@group
 $ cvs -d :pserver:anoncvs@@subversions.gnu.org:/home/cvs \
    login
 Password: @key{ENTER}
 $ cvs -d :pserver:anoncvs@@subversions.gnu.org:/home/cvs \
    checkout grub
@end group
@end example
 Get the recent version of GNU Automake from the CVS to regenerate
@file{Makefile.in}s. See @url{http://sourceware.cygnus.com/automake/},
 for more information.
@node Reporting bugs
@appendix Reporting bugs
 When you encounter any problem or bug, please submit it to
@email{bug-grub@@gnu.org} with information about your computer and what
 you did @emph{as much as possible}. Take a look at this list before you
 send e-mail to the address:
@itemize @bullet
@item
 Write what you did and what messages were printed on the screen in
 detail. Don't paraphrase them. Please describe them as they were.
@item
 Explain what you wanted to do. It is very useful to know your purpose
 and your wish, and how GRUB didn't satisfy you.
@item
 Inform us of the information about your GRUB. What version were you
 using? Which were you using the grub shell or the boot images? If using
 the grub shell, tell us what operating system was used to run it. And,
 if you ran @command{configure} with some options when building GRUB, it
 would be a good thing to let us know how to build it.
@item
 The information on your hardware is also essential. These are especially
 important: the geometries and the partition tables of your hard disk
 drives and your BIOS.
@item
 Write down anything that you think might be related. If you are not sure
 whether to state a fact or leave it out, state it! Reporting too many
 things is quite better than omitting an important thing.
@end itemize
@node Index
@unnumbered Index
@c Currently, we use only the Concept Index.
@printindex cp
--- a/docs/grub-new.texi
+++ b/docs/grub-new.texi
--- a/docs/grub.texi
+++ b/docs/grub.texi
--- a/docs/internals.texi
+++ b/docs/internals.texi
@ -0,0 +1,427 @@
@node Internals
@chapter Hacking GRUB
 This chapter documents the user-invisible aspect of GRUB.
 As a general rule of software development, it is impossible to keep the
 descriptions of the internals up-to-date, and it is quite hard to
 document everything. So refer to the source code, whenever you are not
 satisfied with this documentation.  Please assume that this gives just
 hints to you.
@menu
 * Memory map::                  The memory map of various components
 * Embedded data::               Embedded variables in GRUB
 * Filesystem interface::        The generic interface for filesystems
 * Command interface::           The generic interface for built-ins
 * Bootstrap tricks::            The bootstrap mechanism used in GRUB
 * I/O ports detection::         How to probe I/O ports used by INT 13H
 * Memory detection::            How to detect all installed RAM
 * Low-level disk I/O::          INT 13H disk I/O interrupts
 * MBR::                         The structure of Master Boot Record
 * Partition table::             The format of partition tables
 * Submitting patches::          Where and how you should send patches
@end menu
@node Memory map
@section The memory map of various components
 GRUB consists of two distinct components, called @dfn{stages}, which are
 loaded at different times in the boot process. Because they run
 mutual-exclusively, sometimes a memory area overlaps with another
 memory area. And, even in one stage, a single memory area can be used
 for various purposes, because their usages are mutually exclusive.
 Here is the memory map of the various components:
@table @asis
@item 0 to 4K-1
 BIOS and real mode interrupts
@item 0x07BE to 0x07FF
 Partition table passed to another boot loader
@item down from 8K-1
 Real mode stack
@item 0x2000 to ?
 The optional Stage 1.5 is loaded here
@item 0x2000 to 0x7FFF
 Command-line buffer for Multiboot kernels and modules
@item 0x7C00 to 0x7DFF
 Stage 1 is loaded here by BIOS or another boot loader
@item 0x7F00 to 0x7F42
 LBA drive parameters
@item 0x8000 to ?
 Stage2 is loaded here
@item The end of Stage 2 to 416K-1
 Heap, in particular used for the menu
@item down from 416K-1
 Protected mode stack
@item 416K to 448K-1
 Filesystem buffer
@item 448K to 479.5K-1
 Raw device buffer
@item 479.5K to 480K-1
 512-byte scratch area
@item 480K to 512K-1
 Buffers for various functions, such as password, command-line, cut and
 paste, and completion.
@item The last 1K of lower memory
 Disk swapping code and data
@end table
 See the file @file{stage2/shared.h}, for more information.
@node Embedded data
@section Embedded variables in GRUB
 Stage 1 and Stage 2 have embedded variables whose locations are
 well-defined, so that the installation can patch the binary file
 directly without recompilation of the stages.
 In Stage 1, these are defined:
@table @code
@item 0x3E
 The version number (not GRUB's, but the installation mechanism's).
@item 0x40
 The boot drive. If it is 0xFF, use a drive passed by BIOS.
@item 0x41
 The flag for if forcing LBA.
@item 0x42
 The starting address of Stage 2.
@item 0x44
 The first sector of Stage 2.
@item 0x48
 The starting segment of Stage 2.
@item 0x1FE
 The signature (@code{0xAA55}).
@end table
 See the file @file{stage1/stage1.S}, for more information.
 In the first sector of Stage 1.5 and Stage 2, the block lists are
 recorded between @code{firstlist} and @code{lastlist}. The address of
@code{lastlist} is determined when assembling the file
@file{stage2/start.S}.
 The trick here is that it is actually read backward, and the first
 8-byte block list is not read here, but after the pointer is decremented
 8 bytes, then after reading it, it decrements again, reads, and so on,
 until it is finished. The terminating condition is when the number of
 sectors to be read in the next block list is zero.
 The format of a block list can be seen from the example in the code just
 before the @code{firstlist} label. Note that it is always from the
 beginning of the disk, but @emph{not} relative to the partition 
 boundaries.
 In the second sector of Stage 1.5 and Stage 2, these are defined:
@table @asis
@item @code{0x6}
 The version number (likewise, the installation mechanism's).
@item @code{0x8}
 The installed partition.
@item @code{0xC}
 The saved entry number.
@item @code{0x10}
 The identifier.
@item @code{0x11}
 The flag for if forcing LBA.
@item @code{0x12}
 The version string (GRUB's).
@item @code{0x12} + @dfn{the length of the version string}
 The name of a configuration file.
@end table
 See the file @file{stage2/asm.S}, for more information.
@node Filesystem interface
@section The generic interface for filesystems
 For any particular partition, it is presumed that only one of the
@dfn{normal} filesystems such as FAT, FFS, or ext2fs can be used, so
 there is a switch table managed by the functions in
@file{disk_io.c}. The notation is that you can only @dfn{mount} one at a
 time.
 The block list filesystem has a special place in the system. In addition
 to the @dfn{normal} filesystem (or even without one mounted), you can
 access disk blocks directly (in the indicated partition) via the block
 list notation. Using the block list filesystem doesn't effect any other
 filesystem mounts.
 The variables which can be read by the filesystem backend are:
@vtable @code
@item current_drive
 The current BIOS drive number (numbered from 0, if a floppy, and
 numbered from 0x80, if a hard disk).
@item current_partition
 The current partition number.
@item current_slice
 The current partition type.
@item saved_drive
 The @dfn{drive} part of the root device.
@item saved_partition
 The @dfn{partition} part of the root device.
@item part_start
 The current partition starting address, in sectors.
@item part_length
 The current partition length, in sectors.
@item print_possibilities
 True when the @code{dir} function should print the possible completions
 of a file, and false when it should try to actually open a file of that
 name.
@item FSYS_BUF
 Filesystem buffer which is 32K in size, to use in any way which the
 filesystem backend desires.
@end vtable
 The variables which need to be written by a filesystem backend are:
@vtable @code
@item filepos
 The current position in the file, in sectors.
@strong{Caution:} the value of @var{filepos} can be changed out from
 under the filesystem code in the current implementation. Don't depend on
 it being the same for later calls into the backend code!
@item filemax
 The length of the file.
@item disk_read_func
 The value of @var{disk_read_hook} @emph{only} during reading of data
 for the file, not any other fs data, inodes, FAT tables, whatever, then
 set to @code{NULL} at all other times (it will be @code{NULL} by
 default). If this isn't done correctly, then the @command{testload} and
@command{install} commands won't work correctly.
@end vtable
 The functions expected to be used by the filesystem backend are:
@ftable @code
@item devread
 Only read sectors from within a partition. Sector 0 is the first sector
 in the partition.
@item grub_read
 If the backend uses the block list code, then @code{grub_read} can be
 used, after setting @var{block_file} to 1.
@item print_a_completion
 If @var{print_possibilities} is true, call @code{print_a_completion} for
 each possible file name. Otherwise, the file name completion won't work.
@end ftable
 The functions expected to be defined by the filesystem backend are
 described at least moderately in the file @file{filesys.h}. Their usage
 is fairly evident from their use in the functions in @file{disk_io.c},
 look for the use of the @var{fsys_table} array.
@strong{Caution:} The semantics are such that then @samp{mount}ing the
 filesystem, presume the filesystem buffer @code{FSYS_BUF} is corrupted,
 and (re-)load all important contents. When opening and reading a file,
 presume that the data from the @samp{mount} is available, and doesn't
 get corrupted by the open/read (i.e. multiple opens and/or reads will be
 done with only one mount if in the same filesystem).
@node Command interface
@section The generic interface for built-ins
 GRUB built-in commands are defined in a uniformal interface, whether
 they are menu-specific or can be used anywhere. The definition of a
 builtin command consists of two parts: the code itself and the table of
 the information.
 The code must be a function which takes two arguments, a command-line
 string and flags, and returns an @samp{int} value. The @dfn{flags}
 argument specifies how the function is called, using a bit mask. The
 return value must be zero if successful, otherwise non-zero. So it is
 normally enough to return @var{errnum}.
 The table of the information is represented by the structure
@code{struct builtin}, which contains the name of the command, a pointer
 to the function, flags, a short description of the command and a long
 description of the command. Since the descriptions are used only for
 help messages interactively, you don't have to define them, if the
 command may not be called interactively (such as @command{title}).
 The table is finally registered in the table @var{builtin_table}, so
 that @code{run_script} and @code{enter_cmdline} can find the
 command. See the files @file{cmdline.c} and @file{builtins.c}, for more
 details.
@node Bootstrap tricks
@section The bootstrap mechanism used in GRUB
 The disk space can be used in a boot loader is very restricted because
 a MBR (@pxref{MBR}) is only 512 bytes but it also contains a partition
 table (@pxref{Partition table}) and a BPB. So the question is how to
 make a boot loader code enough small to be fit in a MBR.
 However, GRUB is a very large program, so we break GRUB into 2 (or 3)
 distinct components, @dfn{Stage 1} and @dfn{Stage 2} (and optionally
@dfn{Stage 1.5}). @xref{Memory map}, for more information.
 We embed Stage 1 in a MBR or in the boot sector of a partition, and
 place Stage 2 in a filesystem. The optional Stage 1.5 can be installed
 in a filesystem, in the @dfn{boot loader} area in a FFS or a ReiserFS,
 and in the sectors right after a MBR, because Stage 1.5 is enough small
 and the sectors right after a MBR is normally an unused region. The size
 of this region is the number of sectors per head minus 1.
 Thus, all Stage1 must do is just load Stage2 or Stage1.5. But even if
 Stage 1 needs not to support the user interface or the filesystem
 interface, it is impossible to make Stage 1 less than 400 bytes, because
 GRUB should support both the CHS mode and the LBA mode (@pxref{Low-level
 disk I/O}).
 The solution used by GRUB is that Stage 1 loads only the first sector of
 Stage 2 (or Stage 1.5) and Stage 2 itself loads the rest. The flow of
 Stage 1 is:
@enumerate
@item
 Initialize the system briefly.
@item
 Detect the geometry and the accessing mode of the @dfn{loading drive}.
@item
 Load the first sector of Stage 2.
@item
 Jump to the starting address of the Stage 2.
@end enumerate
 The flow of Stage 2 (and Stage 1.5) is:
@enumerate
@item
 Load the rest of itself to the real starting address, that is, the
 starting address plus 512 bytes. The block lists are stored in the last
 part of the first sector.
@item
 Long jump to the real starting address.
@end enumerate
 Note that Stage 2 (or Stage 1.5) does not probe the geometry
 or the accessing mode of the @dfn{loading drive}, since Stage 1 has
 already probed them.
@node I/O ports detection
@section How to probe I/O ports used by INT 13H
 FIXME: I will write this chapter after implementing the new technique.
@node Memory detection
@section How to detect all installed RAM
 FIXME: I doubt if Erich didn't write this chapter only himself wholly,
 so I will rewrite this chapter.
@node Low-level disk I/O
@section INT 13H disk I/O interrupts
 FIXME: I'm not sure where some part of the original chapter is derived,
 so I will rewrite this chapter.
@node MBR
@section The structure of Master Boot Record
 FIXME: Likewise.
@node Partition table
@section The format of partition tables
 FIXME: Probably the original chapter is derived from "How It Works", so
 I will rewrite this chapter.
@node Submitting patches
@section Where and how you should send patches
 When you write patches for GRUB, please send them to the mailing list
@email{bug-grub@@gnu.org}. Here is the list of items of which you
 should take care:
@itemize @bullet
@item
 Please make your patch as small as possible. Generally, it is not a good
 thing to make one big patch which changes many things. Instead,
 segregate features and produce many patches.
@item
 Use as late code as possible, for the original code. The CVS repository
 always has the current version (@pxref{Obtaining and Building GRUB}).
@item
 Write ChangeLog entries. @xref{Change Logs, , Change Logs, standards,
 GNU Coding Standards}, if you don't know how to write ChangeLog.
@item
 Make patches in unified diff format. @samp{diff -urN} is appropriate in
 most cases.
@item
 Don't make patches reversely. Reverse patches are difficult to read and
 use.
@item
 Be careful enough of the license term and the copyright. Because GRUB
 is under GNU General Public License, you may not steal code from
 software whose license is incompatible against GPL. And, if you copy
 code written by others, you must not ignore their copyrights. Feel free
 to ask GRUB maintainers, whenever you are not sure what you should do.
@item
 If your patch is too large to send in e-mail, put it at somewhere we can
 see. Usually, you shouldn't send e-mail over 20K.
@end itemize
--- a/docs/prog-ref.texi
+++ b/docs/prog-ref.texi
--- a/docs/stamp-vti
+++ b/docs/stamp-vti
@ -1,3 +1,3 @@
-@set UPDATED 22 October 2000
+@set UPDATED 8 February 2001
@set EDITION 0.5.97
@set VERSION 0.5.97
--- a/docs/tutorial.texi
+++ b/docs/tutorial.texi
--- a/docs/user-ref.texi
+++ b/docs/user-ref.texi
--- a/docs/version.texi
+++ b/docs/version.texi
@ -1,3 +1,3 @@
-@set UPDATED 22 October 2000
+@set UPDATED 8 February 2001
@set EDITION 0.5.97
@set VERSION 0.5.97