From ea8f03e60cc0c0bea5cb12638161eecdb5f31c03 Mon Sep 17 00:00:00 2001 From: fzielcke Date: Wed, 3 Sep 2008 20:15:15 +0000 Subject: [PATCH] we want block list' --- docs/grub.texi | 28 ++++++++++++++-------------- docs/internals.texi | 16 ++++++++-------- docs/multiboot.texi | 2 +- 3 files changed, 23 insertions(+), 23 deletions(-) diff --git a/docs/grub.texi b/docs/grub.texi index 8ff3fddeb..a533c4ac0 100644 --- a/docs/grub.texi +++ b/docs/grub.texi @@ -266,7 +266,7 @@ devices, partitions, and files in a directory depending on context. @item Support multiple filesystem types Support multiple filesystem types transparently, plus a useful explicit -block list notation. The currently supported filesystem types are +blocklist notation. The currently supported filesystem types are @dfn{BSD FFS}, @dfn{DOS FAT16 and FAT32}, @dfn{Minix fs}, @dfn{Linux ext2fs}, @dfn{ReiserFS}, @dfn{JFS}, @dfn{XFS}, and @dfn{VSTa fs}. @xref{Filesystem}, for more information. @@ -822,7 +822,7 @@ grub> @kbd{chainloader +1} @samp{+1} indicates that GRUB should read one sector from the start of the partition. The complete description about this syntax can be found -in @ref{Block list syntax}. +in @ref{blocklist syntax}. @item Run the command @command{boot} (@pxref{boot}). @@ -1748,7 +1748,7 @@ sector is 512 bytes, the size of this image is exactly 512 bytes. All @file{stage1} must do is to load Stage 2 or Stage 1.5 from a local disk. Because of the size restriction, @file{stage1} encodes the -location of Stage 2 (or Stage 1.5) in a block list format, so it never +location of Stage 2 (or Stage 1.5) in a blocklist format, so it never understand any filesystem structure. @item stage2 @@ -1808,7 +1808,7 @@ you see the files in a device or use the command @command{find} @menu * Device syntax:: How to specify devices * File name syntax:: How to specify files -* Block list syntax:: How to specify block lists +* blocklist syntax:: How to specify blocklists @end menu @@ -1863,7 +1863,7 @@ a GRUB bootable CD-ROM}, for details. @section How to specify files There are two ways to specify files, by @dfn{absolute file name} and by -@dfn{block list}. +@dfn{blocklist}. An absolute file name resembles a Unix absolute file name, using @samp{/} for the directory separator (not @samp{\} as in DOS). One @@ -1875,10 +1875,10 @@ say, @samp{(hd1,0)} by the command @command{root} (@pxref{root}), then @code{/boot/kernel} is the same as @code{(hd1,0)/boot/kernel}. -@node Block list syntax -@section How to specify block lists +@node blocklist syntax +@section How to specify blocklists -A block list is used for specifying a file that doesn't appear in the +A blocklist is used for specifying a file that doesn't appear in the filesystem, like a chainloader. The syntax is @code{[@var{offset}]+@var{length}[,[@var{offset}]+@var{length}]@dots{}}. Here is an example: @@ -1891,7 +1891,7 @@ This represents that GRUB should read blocks 0 through 99, block 200, and blocks 300 through 599. If you omit an offset, then GRUB assumes the offset is zero. -Like the file name syntax (@pxref{File name syntax}), if a block list +Like the file name syntax (@pxref{File name syntax}), if a blocklist does not contain a device name, then GRUB uses GRUB's @dfn{root device}. So @code{(hd0,1)+1} is the same as @code{+1} when the root device is @samp{(hd0,1)}. @@ -2643,7 +2643,7 @@ you forget a command, you can run the command @command{help} (@pxref{help}). @menu -* blocklist:: Get the block list notation of a file +* blocklist:: Get the blocklist notation of a file * boot:: Start up your operating system * cat:: Show the contents of a file * chainloader:: Chain-load another boot loader @@ -2688,7 +2688,7 @@ you forget a command, you can run the command @command{help} @subsection blocklist @deffn Command blocklist file -Print the block list notation of the file @var{file}. @xref{Block list +Print the blocklist notation of the file @var{file}. @xref{blocklist syntax}. @end deffn @@ -2721,7 +2721,7 @@ grub> @kbd{cat /etc/fstab} @deffn Command chainloader [@option{--force}] file Load @var{file} as a chain-loader. Like any other file loaded by the -filesystem code, it can use the block list notation to grab the first +filesystem code, it can use the blocklist notation to grab the first sector of the current partition with @samp{+1}. If you specify the option @option{--force}, then load @var{file} forcibly, whether it has a correct signature or not. This is required when you want to load a @@ -2905,7 +2905,7 @@ In short, it will perform a full install presuming the Stage 2 or Stage In slightly more detail, it will load @var{stage1_file}, validate that it is a GRUB Stage 1 of the right version number, install in it a -block list for loading @var{stage2_file} as a Stage 2. If the option +blocklist for loading @var{stage2_file} as a Stage 2. If the option @option{d} is present, the Stage 1 will always look for the actual disk @var{stage2_file} was installed on, rather than using the booting drive. The Stage 2 will be loaded at address @var{addr}, which must be @@ -3313,7 +3313,7 @@ The following is a comprehensive list of error messages for the Stage 2 description): @table @asis -@item 1 : Filename must be either an absolute filename or block list +@item 1 : Filename must be either an absolute filename or blocklist This error is returned if a file name is requested which doesn't fit the syntax/rules listed in the @ref{Filesystem}. diff --git a/docs/internals.texi b/docs/internals.texi index c6fc092f8..ece8e6cc6 100644 --- a/docs/internals.texi +++ b/docs/internals.texi @@ -120,18 +120,18 @@ The signature (@code{0xAA55}). 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 +In the first sector of Stage 1.5 and Stage 2, the blocklists 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-byte blocklist 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. +sectors to be read in the next blocklist is zero. -The format of a block list can be seen from the example in the code just +The format of a blocklist 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. @@ -173,10 +173,10 @@ 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 +The blocklist 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 +list notation. Using the blocklist filesystem doesn't effect any other filesystem mounts. The variables which can be read by the filesystem backend are: @@ -243,7 +243,7 @@ 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 +If the backend uses the blocklist code, then @code{grub_read} can be used, after setting @var{block_file} to 1. @item print_a_completion @@ -339,7 +339,7 @@ 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 +starting address plus 512 bytes. The blocklists are stored in the last part of the first sector. @item diff --git a/docs/multiboot.texi b/docs/multiboot.texi index b28408f85..c069fae39 100644 --- a/docs/multiboot.texi +++ b/docs/multiboot.texi @@ -158,7 +158,7 @@ across a network. Disk-based boot loaders may use a variety of techniques to find the relevant OS image and boot module data on disk, such as by interpretation of specific file systems (e.g. the BSD/Mach boot loader), -using precalculated @dfn{block lists} (e.g. LILO), loading from a +using precalculated @dfn{blocklists} (e.g. LILO), loading from a special @dfn{boot partition} (e.g. OS/2), or even loading from within another operating system (e.g. the VSTa boot code, which loads from DOS). Similarly, network-based boot loaders could use a variety of