GNU GRUB Developers Manual 2.02~beta2

Table of Contents

Next: , Up: (dir)   [Contents][Index]

GNU GRUB developer manual

This is the developer documentation of GNU GRUB, the GRand Unified Bootloader, a flexible and powerful boot loader program for a wide range of architectures.

This edition documents version 2.02~beta2.

This developer manual is for GNU GRUB (version 2.02~beta2, 6 August 2024).

Copyright © 1999,2000,2001,2002,2004,2005,2006,2008,2009,2010,2011 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections.


Next: , Previous: Top, Up: Top   [Contents][Index]

1 Getting the source code

GRUB is maintained using the GIT revision control system. To fetch:

git clone git://git.sv.gnu.org/grub.git

Web access is available under

http://git.savannah.gnu.org/cgit/grub.git/

The branches available are:

master

Main development branch.

grub-legacy

GRUB 0.97 codebase. Kept for reference and legal reasons

multiboot

Multiboot specfication

multiboot2

Multiboot2 specfication

developer branches

Prefixed with developer name. Every developer of a team manages his own branches. Developer branches do not need changelog entries.

Once you have used git clone to fetch an initial copy of a branch, you can use git pull to keep it up to date. If you have modified your local version, you may need to resolve conflicts when pulling.


Next: , Previous: Getting the source code, Up: Top   [Contents][Index]

2 Coding style

Basically we follow the GNU Coding Standards. We define additional conventions for GRUB here.


Next: , Up: Coding style   [Contents][Index]

2.1 Naming Conventions

All global symbols (i.e. functions, variables, types, and macros) must have the prefix grub_ or GRUB_. The all capital form is used only by macros.


Next: , Previous: Naming Conventions, Up: Coding style   [Contents][Index]

2.2 Functions

If a function is global, its name must be prefixed with grub_ and must consist of only small letters. If the function belongs to a specific function module, the name must also be prefixed with the module name. For example, if a function is for file systems, its name is prefixed with grub_fs_. If a function is for FAT file system but not for all file systems, its name is prefixed with grub_fs_fat_. The hierarchy is noted this way.

After a prefix, a function name must start with a verb (such as get or is). It must not be a noun. Some kind of abbreviation is permitted, as long as it wouldn’t make code less readable (e.g. init).

If a function is local, its name may not start with any prefix. It must start with a verb.


Next: , Previous: Functions, Up: Coding style   [Contents][Index]

2.3 Variables

The rule is mostly the same as functions, as noted above. If a variable is global, its name must be prefixed with grub_ and must consist of only small letters. If the variable belongs to a specific function module, the name must also be prefixed with the module name. For example, if a function is for dynamic loading, its name is prefixed with grub_dl_. If a variable is for ELF but not for all dynamic loading systems, its name is prefixed with grub_dl_elf_.

After a prefix, a variable name must start with a noun or an adjective (such as name or long) and it should end with a noun. Some kind of abbreviation is permitted, as long as it wouldn’t make code less readable (e.g. i18n).

If a variable is global in the scope of a single file (i.e. it is declared with static), its name may not start with any prefix. It must start with a noun or an adjective.

If a variable is local, you may choose any shorter name, as long as it wouldn’t make code less readable (e.g. i).


Next: , Previous: Variables, Up: Coding style   [Contents][Index]

2.4 Types

The name of a type must be prefixed with grub_ and must consist of only small letters. If the type belongs to a specific function module, the name must also be prefixed with the module name. For example, if a type is for OS loaders, its name is prefixed with grub_loader_. If a type is for Multiboot but not for all OS loaders, its name is prefixed with grub_loader_linux_.

The name must be suffixed with _t, to emphasize the fact that it is a type but not a variable or a function.


Next: , Previous: Types, Up: Coding style   [Contents][Index]

2.5 Macros

If a macro is global, its name must be prefixed with GRUB_ and must consist of only large letters. Other rules are the same as functions or variables, depending on whether a macro is used like a function or a variable.


Next: , Previous: Macros, Up: Coding style   [Contents][Index]

2.6 Comments

All comments shall be C-style comments, of the form ‘/* … */’.

Comments shall be placed only on a line by themselves. They shall not be placed together with code, variable declarations, or other non-comment entities. A comment should be placed immediately preceding the entity it describes.

Acceptable:

/* The page # that is the front buffer.  */
int displayed_page;
/* The page # that is the back buffer.  */
int render_page;

Unacceptable:

int displayed_page;           /* The page # that is the front buffer. */
int render_page;              /* The page # that is the back buffer. */

Previous: Comments, Up: Coding style   [Contents][Index]

2.7 Multi-Line Comments

Comments spanning multiple lines shall be formatted with all lines after the first aligned with the first line.

Asterisk characters should not be repeated a the start of each subsequent line.

Acceptable:

/* This is a comment
   which spans multiple lines.
   It is long.  */

Unacceptable:

/*
 * This is a comment
 * which spans multiple lines.
 * It is long. */

The opening ‘/*’ and closing ‘*/’ should be placed together on a line with text.


Next: , Previous: Coding style, Up: Top   [Contents][Index]

3 Finding your way around

Here is a brief map of the GRUB code base.

GRUB uses Autoconf and Automake, with most of the Automake input generated by AutoGen. The top-level build rules are in configure.ac, grub-core/Makefile.core.def, and Makefile.util.def. Each block in a *.def file represents a build target, and specifies the source files used to build it on various platforms. The *.def files are processed into AutoGen input by gentpl.py (which you only need to look at if you are extending the build system). If you are adding a new module which follows an existing pattern, such as a new command or a new filesystem implementation, it is usually easiest to grep grub-core/Makefile.core.def and Makefile.util.def for an existing example of that pattern to find out where it should be added.

In general, code that may be run at boot time is in a subdirectory of grub-core, while code that is only run from within a full operating system is in a subdirectory of the top level.

Low-level boot code, such as the MBR implementation on PC BIOS systems, is in the grub-core/boot/ directory.

The GRUB kernel is in grub-core/kern/. This contains core facilities such as the device, disk, and file frameworks, environment variable handling, list processing, and so on. The kernel should contain enough to get up to a rescue prompt. Header files for kernel facilities, among others, are in include/.

Terminal implementations are in grub-core/term/.

Disk access code is spread across grub-core/disk/ (for accessing the disk devices themselves), grub-core/partmap/ (for interpreting partition table data), and grub-core/fs/ (for accessing filesystems). Note that, with the odd specialised exception, GRUB only contains code to read from filesystems and tries to avoid containing any code to write to filesystems; this lets us confidently assure users that GRUB cannot be responsible for filesystem corruption.

PCI and USB bus handling is in grub-core/bus/.

Video handling code is in grub-core/video/. The graphical menu system uses this heavily, but is in a separate directory, grub-core/gfxmenu/.

Most commands are implemented by files in grub-core/commands/, with the following exceptions:

There are a few other special-purpose exceptions; grep for them if they matter to you.


Next: , Previous: Finding your way around, Up: Top   [Contents][Index]

4 Contributing changes

Contributing changes to GRUB 2 is welcomed activity. However we have a bit of control what kind of changes will be accepted to GRUB 2. Therefore it is important to discuss your changes on grub-devel mailing list (see MailingLists). On this page there are some basic details on the development process and activities.

First of all you should come up with the idea yourself what you want to contribute. If you do not have that beforehand you are advised to study this manual and try GRUB 2 out to see what you think is missing from there.

Here are additional pointers:

If you intended to make changes to GRUB Legacy (<=0.97) those are not accepted anymore.


Next: , Up: Contributing Changes   [Contents][Index]

4.1 Getting started


Next: , Previous: Getting started, Up: Contributing Changes   [Contents][Index]

4.2 Typical Developer Experience

The typical experience for a developer in this project is the following:

  1. You find yourself wanting to do something (e.g. fixing a bug).
  2. You show some result in the mailing list or the IRC.
  3. You are getting to be known to other developers.
  4. You accumulate significant amount of contribution, so copyright assignment is processed.
  5. You are free to check in your changes on your own, legally speaking.

At this point, it is rather annoying that you ought to ask somebody else every change to be checked in. For efficiency, it is far better, if you can commit it yourself. Therefore, our policy is to give you the write permission to our official repository, once you have shown your skill and will, and the FSF clerks have dealt with your copyright assignment.


Previous: Typical Developer Experience, Up: Contributing Changes   [Contents][Index]

4.3 When you are approved for write access to project’s files

As you might know, GRUB is hosted on https://savannah.gnu.org/projects/grub Savannah, thus the membership is managed by Savannah. This means that, if you want to be a member of this project:

  1. You need to create your own account on Savannah.
  2. You can submit “Request for Inclusion” from “My Groups” on Savannah.

Then, one of the admins can approve your request, and you will be a member. If you don’t want to use the Savannah interface to submit a request, you can simply notify the admins by email or something else, alternatively. But you still need to create an account beforehand.

NOTE: we sometimes receive a “Request for Inclusion” from an unknown person. In this case, the request would be just discarded, since it is too dangerous to allow a stranger to be a member, which automatically gives him a commit right to the repository, both for a legal reason and for a technical reason.

If your intention is to just get started, please do not submit a inclusion request. Instead, please subscribe to the mailing list, and communicate first (e.g. sending a patch, asking a question, commenting on another message...).


Next: , Previous: Contributing Changes, Up: Top   [Contents][Index]

5 Porting

GRUB2 is designed to be easily portable accross platforms. But because of the nature of bootloader every new port must be done separately. Here is how I did MIPS (loongson and ARC) and Xen ports. Note than this is more of suggestions, not absolute truth.

First of all grab any architecture specifications you can find in public (please avoid NDA).

First stage is “Hello world”. I’ve done it outside of GRUB for simplicity. Your task is to have a small program which is loadable as bootloader and clearly shows its presence to you. If you have easily accessible console you can just print a message. If you have a mapped framebuffer you know address of, you can draw a square. If you have a debug facility, just hanging without crashing might be enough. For the first stage you can choose to load the bootloader across the network since format for network image is often easier than for local boot and it skips the need of small intermediary stages and nvram handling. Additionally you can often have a good idea of the needed format by running “file” on any netbootable executable for given platform.

This program should probably have 2 parts: an assembler and C one. Assembler one handles BSS cleaning and other needed setup (on some platforms you may need to switch modes or copy the executable to its definitive position). So your code may look like (x86 assembly for illustration purposes)

        .globl _start
_start:
	movl	$_bss_start, %edi
	movl	$_end, %ecx
	subl	%edi, %ecx
	xorl	%eax, %eax
	cld
	rep
	stosb
        call main
static const char msg[] = "Hello, world";

void
putchar (int c)
{
  ...
}

void
main (void)
{
  const char *ptr = msg;
  while (*ptr)
    putchar (*ptr++);
  while (1);
}

Sometimes you need a third file: assembly stubs for ABI-compatibility.

Once this file is functional it’s time to move it into GRUB2. The startup assembly file goes to grub-core/kern/$cpu/$platform/startup.S. You should also include grub/symbol.h and replace call to entry point with call to EXT_C(grub_main). The C file goes to grub-core/kern/$cpu/$platform/init.c and its entry point is renamed to void grub_machine_init (void). Keep final infinite loop for now. Stubs file if any goes to grub-core/kern/$cpu/$platform/callwrap.S. Sometimes either $cpu or $platform is dropped if file is used on several cpus respectivelyplatforms. Check those locations if they already have what you’re looking for.

Then modify in configure.ac the following parts:

CPU names:

case "$target_cpu" in
  i[[3456]]86)	target_cpu=i386 ;;
  amd64)	target_cpu=x86_64 ;;
  sparc)	target_cpu=sparc64 ;;
  s390x)	target_cpu=s390 ;;
  ...
esac

Sometimes CPU have additional architecture names which don’t influence booting. You might want to have some canonical name to avoid having bunch of identical platforms with different names.

NOTE: it doesn’t influence compile optimisations which depend solely on chosen compiler and compile options.

if test "x$with_platform" = x; then
  case "$target_cpu"-"$target_vendor" in
    i386-apple) platform=efi ;;
    i386-*) platform=pc ;;
    x86_64-apple) platform=efi ;;
    x86_64-*) platform=pc ;;
    powerpc-*) platform=ieee1275 ;;
    ...
  esac
else
  ...
fi

This part deals with guessing the platform from CPU and vendor. Sometimes you need to use 32-bit mode for booting even if OS runs in 64-bit one. If so add your platform to:

case "$target_cpu"-"$platform" in
  x86_64-efi) ;;
  x86_64-emu) ;;
  x86_64-*) target_cpu=i386 ;;
  powerpc64-ieee1275) target_cpu=powerpc ;;
esac

Add your platform to the list of supported ones:

case "$target_cpu"-"$platform" in
  i386-efi) ;;
  x86_64-efi) ;;
  i386-pc) ;;
  i386-multiboot) ;;
  i386-coreboot) ;;
  ...
esac

If explicit -m32 or -m64 is needed add it to:

case "$target_cpu" in
  i386 | powerpc) target_m32=1 ;;
  x86_64 | sparc64) target_m64=1 ;;
esac

Finally you need to add a conditional to the following block:

AM_CONDITIONAL([COND_mips_arc], [test x$target_cpu = xmips -a x$platform = xarc])
AM_CONDITIONAL([COND_sparc64_ieee1275], [test x$target_cpu = xsparc64 -a x$platform = xieee1275])
AM_CONDITIONAL([COND_powerpc_ieee1275], [test x$target_cpu = xpowerpc -a x$platform = xieee1275])

Next stop is gentpl.py. You need to add your platform to the list of supported ones (sorry that this list is duplicated):

GRUB_PLATFORMS = [ "emu", "i386_pc", "i386_efi", "i386_qemu", "i386_coreboot",
                   "i386_multiboot", "i386_ieee1275", "x86_64_efi",
                   "mips_loongson", "sparc64_ieee1275",
                   "powerpc_ieee1275", "mips_arc", "ia64_efi",
                   "mips_qemu_mips", "s390_mainframe" ]

You may also want already to add new platform to one or several of available groups. In particular we always have a group for each CPU even when only one platform for given CPU is available.

Then comes grub-core/Makefile.core.def. In the block “kernel” you’ll need to define ldflags for your platform ($cpu_$platform_ldflags). You also need to declare startup asm file ($cpu_$platform_startup) as well as any other files (e.g. init.c and callwrap.S) (e.g. $cpu_$platform = kern/$cpu/$platform/init.c). At this stage you will also need to add dummy dl.c and cache.S with functions grub_err_t grub_arch_dl_check_header (void *ehdr), grub_err_t grub_arch_dl_relocate_symbols (grub_dl_t mod, void *ehdr) (dl.c) and void grub_arch_sync_caches (void *address, grub_size_t len) (cache.S). They won’t be used for now.

You will need to create directory include/$cpu/$platform and a file include/$cpu/types.h. The later folowing this template:

#ifndef GRUB_TYPES_CPU_HEADER
#define GRUB_TYPES_CPU_HEADER	1

/* The size of void *.  */
#define GRUB_TARGET_SIZEOF_VOID_P	4

/* The size of long.  */
#define GRUB_TARGET_SIZEOF_LONG		4

/* mycpu is big-endian.  */
#define GRUB_TARGET_WORDS_BIGENDIAN	1
/* Alternatively: mycpu is little-endian.  */
#undef GRUB_TARGET_WORDS_BIGENDIAN

#endif /* ! GRUB_TYPES_CPU_HEADER */

You will also need to add a dummy file to datetime and setjmp modules to avoid any of it having no files. It can be just completely empty at this stage.

You’ll need to make grub-mkimage.c (util/grub_mkimage.c) aware of the needed format. For most commonly used formats like ELF, PE, aout or raw the support is already present and you’ll need to make it follow the existant code paths for your platform adding adjustments if necessary. When done compile:

./autogen.sh
./configure --target=$cpu --with-platform=$platform TARGET_CC=.. OBJCOPY=... STRIP=...
make > /dev/null

And create image

./grub-mkimage -d grub-core -O $format_id -o test.img

And it’s time to test your test.img.

If it works next stage is to have heap, console and timer.

To have the heap working you need to determine which regions are suitable for heap usage, allocate them from firmware and map (if applicable). Then call grub_mm_init_region (vois *start, grub_size_t s) for every of this region. As a shortcut for early port you can allocate right after _end or have a big static array for heap. If you do you’ll probably need to come back to this later. As for output console you should distinguish between an array of text, terminfo or graphics-based console. Many of real-world examples don’t fit perfectly into any of these categories but one of the models is easier to be used as base. In second and third case you should add your platform to terminfokernel respectively videoinkernel group. A good example of array of text is i386-pc (kern/i386/pc/init.c and term/i386/pc/console.c). Of terminfo is ieee1275 (kern/ieee1275/init.c and term/ieee1275/console.c). Of video is loongson (kern/mips/loongson/init.c). Note that terminfo has to be inited in 2 stages: one before (to get at least rudimentary console as early as possible) and another after the heap (to get full-featured console). For the input there are string of keys, terminfo and direct hardware. For string of keys look at i386-pc (same files), for termino ieee1275 (same files) and for hardware loongson (kern/mips/loongson/init.c and term/at_keyboard.c).

For the timer you’ll need to call grub_install_get_time_ms (...) with as sole argument a function returning a grub_uint64_t of a number of milliseconds elapsed since arbitrary point in the past.

Once these steps accomplished you can remove the inifinite loop and you should be able to get to the minimal console. Next step is to have module loading working. For this you’ll need to fill kern/$cpu/dl.c and kern/$cpu/cache.S with real handling of relocations and respectively the real sync of I and D caches. Also you’ll need to decide where in the image to store the modules. Usual way is to have it concatenated at the end. In this case you’ll need to modify startup.S to copy modules out of bss to let’s say ALIGN_UP (_end, 8) before cleaning out bss. You’ll probably find useful to add total_module_size field to startup.S. In init.c you need to set grub_modbase to the address where modules can be found. You may need grub_modules_get_end () to avoid declaring the space occupied by modules as usable for heap. You can test modules with:

./grub-mkimage -d grub-core -O $format_id -o test.img hello

and then running “hello” in the shell.

Once this works, you should think of implementing disk access. Look around disk/ for examples.

Then, very importantly, you probably need to implement the actual loader (examples available in loader/)

Last step to have minimally usable port is to add support to grub-install to put GRUB in a place where firmware or platform will pick it up.

Next steps are: filling datetime.c, setjmp.S, network (net/drivers), video (video/), halt (lib/), reboot (lib/).

Please add your platform to Platform limitations and Supported kernels chapter in user documentation and mention any steps you skipped which result in reduced features or performance. Here is the quick checklist of features. Some of them are less important than others and skipping them is completely ok, just needs to be mentioned in user documentation.

Checklist:


Next: , Previous: Porting, Up: Top   [Contents][Index]

6 Error Handling

Error handling in GRUB 2 is based on exception handling model. As C language doesn’t directly support exceptions, exception handling behavior is emulated in software.

When exception is raised, function must return to calling function. If calling function does not provide handling of the exception it must return back to its calling function and so on, until exception is handled. If exception is not handled before prompt is displayed, error message will be shown to user.

Exception information is stored on grub_errno global variable. If grub_errno variable contains value GRUB_ERR_NONE, there is no active exception and application can continue normal processing. When grub_errno has other value, it is required that application code either handles this error or returns instantly to caller. If function is with return type grub_err_t is about to return GRUB_ERR_NONE, it should not set grub_errno to that value. Only set grub_errno in cases where there is error situation.

Simple exception forwarder.

grub_err_t
forwarding_example (void)
{
  /* Call function that might cause exception.  */
  foobar ();

  /* No special exception handler, just forward possible exceptions.  */
  if (grub_errno != GRUB_ERR_NONE)
    {
      return grub_errno;
    }

  /* All is OK, do more processing.  */

  /* Return OK signal, to caller.  */
  return GRUB_ERR_NONE;
}

Error reporting has two components, the actual error code (of type grub_err_t) and textual message that will be displayed to user. List of valid error codes is listed in header file include/grub/err.h. Textual error message can contain any textual data. At time of writing, error message can contain up to 256 characters (including terminating NUL). To ease error reporting there is a helper function grub_error that allows easier formatting of error messages and should be used instead of writing directly to global variables.

Example of error reporting.

grub_err_t
failing_example ()
{
  return grub_error (GRUB_ERR_FILE_NOT_FOUND, 
                     "Failed to read %s, tried %d times.",
                     "test.txt",
                     10);
}

If there is a special reason that error code does not need to be taken account, grub_errno can be zeroed back to GRUB_ERR_NONE. In cases like this all previous error codes should have been handled correctly. This makes sure that there are no unhandled exceptions.

Example of zeroing grub_errno.

grub_err_t
probe_example ()
{
  /* Try to probe device type 1.  */
  probe_for_device ();
  if (grub_errno == GRUB_ERR_NONE)
    {
      /* Device type 1 was found on system.  */
      register_device ();
      return GRUB_ERR_NONE;
    }
  /* Zero out error code.  */
  grub_errno = GRUB_ERR_NONE;

  /* No device type 1 found, try to probe device type 2.  */
  probe_for_device2 ();
  if (grub_errno == GRUB_ERR_NONE)
    {
      /* Device type 2 was found on system.  */
      register_device2 ();
      return GRUB_ERR_NONE;
    }
  /* Zero out error code.  */
  grub_errno = GRUB_ERR_NONE;

  /* Return custom error message.  */
  return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "No device type 1 or 2 found.");
}

Some times there is a need to continue processing even if there is a error state in application. In situations like this, there is a needed to save old error state and then call other functions that might fail. To aid in this, there is a error stack implemented. Error state can be pushed to error stack by calling function grub_error_push (). When processing has been completed, grub_error_pop () can be used to pop error state from stack. Error stack contains predefined amount of error stack items. Error stack is protected for overflow and marks these situations so overflow error does not get unseen. If there is no space available to store error message, it is simply discarded and overflow will be marked as happened. When overflow happens, it most likely will corrupt error stack consistency as for pushed error there is no matching pop, but overflow message will be shown to inform user about the situation. Overflow message will be shown at time when prompt is about to be drawn.

Example usage of error stack.

/* Save possible old error message.  */
grub_error_push ();

/* Do your stuff here.  */
call_possibly_failing_function ();

if (grub_errno != GRUB_ERR_NONE)
  {
    /* Inform rest of the code that there is error (grub_errno
       is set). There is no pop here as we want both error states 
       to be displayed.  */
    return;
  }

/* Restore old error state by popping previous item from stack. */
grub_error_pop ();

Next: , Previous: Error Handling, Up: Top   [Contents][Index]

7 Stack and heap size

On emu stack and heap are just normal host OS stack and heap. Stack is typically 8 MiB although it’s OS-dependent.

On i386-pc, i386-coreboot, i386-qemu and i386-multiboot the stack is 60KiB. All available space between 1MiB and 4GiB marks is part of heap.

On *-xen stack is 4MiB. If compiled for x86-64 with GCC 4.4 or later adressable space is unlimited. When compiled for x86-64 with older GCC version adressable space is limited to 2GiB. When compiling for i386 adressable space is limited to 4GiB. All adressable pages except the ones for stack, GRUB binary, special pages and page table are in the heap.

On *-efi GRUB uses same stack as EFI. If compiled for x86-64 with GCC 4.4 or later adressable space is unlimited. When compiled for x86-64 with older GCC version adressable space is limited to 2GiB. For all other platforms adressable space is limited to 4GiB. GRUB allocates pages from EFI for its heap, at most 1.6 GiB.

On i386-ieee1275 and powerpc-ieee1275 GRUB uses same stack as IEEE1275. It allocates at most 32MiB for its heap.

On sparc64-ieee1275 stack is 256KiB and heap is 2MiB.

On mips(el)-qemu_mips and mipsel-loongson stack is 2MiB (everything below GRUB image) and everything above GRUB image (from 2MiB + kernel size) until 256MiB is part of heap.

On mips-arc stack is 2MiB (everything below GRUB image) and everything above GRUB image(from 2MiB + kernel size) until 128MiB is part of heap.

On mipsel-arc stack is 2MiB (everything below GRUB image which is not part of ARC) and everything above GRUB image (from 7MiB + kernel size) until 256MiB is part of heap.

On arm-uboot stack is 256KiB and heap is 2MiB.

In short:

PlatformStackHeap
emu8 MiB?
i386-pc60 KiB< 4 GiB
i386-coreboot60 KiB< 4 GiB
i386-multiboot60 KiB< 4 GiB
i386-qemu60 KiB< 4 GiB
*-efi?< 1.6 GiB
i386-ieee1275?< 32 MiB
powerpc-ieee1275?< 32 MiB
sparc64-ieee1275256KiB2 MiB
arm-uboot256KiB2 MiB
mips(el)-qemu_mips2MiB253 MiB
mipsel-loongson2MiB253 MiB
mips-arc2MiB125 MiB
mipsel-arc2MiB248 MiB
x86_64-xen (GCC >= 4.4)4MiBunlimited
x86_64-xen (GCC < 4.4)4MiB< 2GiB
i386-xen4MiB< 4GiB

Next: , Previous: Stack and heap size, Up: Top   [Contents][Index]

8 BIOS port memory map

StartEndUsage
00x1000 - 1BIOS and real mode interrupts
0x07BE0x07FFPartition table passed to another boot loader
?0x2000 - 1Real mode stack
0x7C000x7D00 - 1Boot sector
0x8000?GRUB kernel
0x680000x71000 - 1Disk buffer
?0x80000 - 1Protected mode stack
?0xA0000 - 1Extended BIOS Data Area
0xA00000xC0000 - 1Video RAM
0xC00000x100000 - 1BIOS
0x100000?Heap and module code

Next: , Previous: BIOS port memory map, Up: Top   [Contents][Index]

9 Video Subsystem

This document contains specification for Video Subsystem for GRUB2. Currently only the usage interface is described in this document. Internal structure of how video drivers are registering and how video driver manager works are not included here.


Next: , Up: Video Subsystem   [Contents][Index]

9.1 Video API

9.1.1 grub_video_setup

9.1.2 grub_video_restore

9.1.3 grub_video_get_info

9.1.4 grub_video_get_blit_format

9.1.5 grub_video_set_palette

9.1.6 grub_video_get_palette

9.1.7 grub_video_set_area_status

9.1.8 grub_video_get_area_status

9.1.9 grub_video_set_viewport

9.1.10 grub_video_get_viewport

9.1.11 grub_video_set_region

9.1.12 grub_video_get_region

9.1.13 grub_video_map_color

9.1.14 grub_video_map_rgb

9.1.15 grub_video_map_rgba

9.1.16 grub_video_unmap_color

9.1.17 grub_video_fill_rect

9.1.18 grub_video_blit_glyph

9.1.19 grub_video_blit_bitmap

9.1.20 grub_video_blit_render_target

9.1.21 grub_video_scroll

9.1.22 grub_video_swap_buffers

9.1.23 grub_video_create_render_target

9.1.24 grub_video_delete_render_target

9.1.25 grub_video_set_active_render_target

9.1.26 grub_video_get_active_render_target


Next: , Previous: Video API, Up: Video Subsystem   [Contents][Index]

9.2 Example usage of Video API

9.2.1 Example of screen setup

grub_err_t rc;
/* Try to initialize video mode 1024 x 768 with direct RGB.  */
rc = grub_video_setup (1024, 768, GRUB_VIDEO_MODE_TYPE_RGB);
if (rc != GRUB_ERR_NONE)
{
  /* Fall back to standard VGA Index Color mode.  */
  rc = grub_video_setup (640, 480, GRUB_VIDEO_MODE_TYPE_INDEX);
  if (rc != GRUB_ERR_NONE)
  {
  /* Handle error.  */
  }
}

9.2.2 Example of setting up console viewport

grub_uint32_t x, y, width, height;
grub_video_color_t color;
struct grub_font_glyph glyph;
grub_err_t rc;
/* Query existing viewport.  */
grub_video_get_viewport (&x, &y, &width, &height);
/* Fill background.  */
color = grub_video_map_color (GRUB_COLOR_BACKGROUND);
grub_video_fill_rect (color, 0, 0, width, height);
/* Setup console viewport.  */
grub_video_set_viewport (x + 10, y + 10, width - 20, height - 20);
grub_video_get_viewport (&x, &y, &width, &height);
color = grub_video_map_color (GRUB_COLOR_CONSOLE_BACKGROUND);
grub_video_fill_rect (color, 0, 0, width, height);
/* Draw text to viewport.  */
color = grub_video_map_color (GRUB_COLOR_CONSOLE_TEXT);
grub_font_get_glyph ('X', &glyph);
grub_video_blit_glyph (&glyph, color, 0, 0);

Previous: Example usage of Video API, Up: Video Subsystem   [Contents][Index]

9.3 Bitmap API

9.3.1 grub_video_bitmap_create

9.3.2 grub_video_bitmap_destroy

9.3.3 grub_video_bitmap_load

9.3.4 grub_video_bitmap_get_width

9.3.5 grub_video_bitmap_get_height

9.3.6 grub_video_bitmap_get_mode_info

9.3.7 grub_video_bitmap_get_data


Next: , Previous: Video Subsystem, Up: Top   [Contents][Index]

10 PFF2 Font File Format


Next: , Up: PFF2 Font File Format   [Contents][Index]

10.1 Introduction

The goal of this format is to provide a bitmap font format that is simple to use, compact, and cleanly supports Unicode.

10.1.1 Goals of the GRUB Font Format

10.1.2 Why Another Font Format?

There are many existing bitmap font formats that GRUB could use. However, there are aspects of these formats that may make them less than suitable for use in GRUB at this time:

BDF

Inefficient storage; uses ASCII to describe properties and hexadecimal numbers in ASCII for the bitmap rows.

PCF

Many format variations such as byte order and bitmap padding (rows padded to byte, word, etc.) would result in more complex code to handle the font format.


Next: , Previous: Introduction, Up: PFF2 Font File Format   [Contents][Index]

10.2 File Structure

A file section consists of a 4-byte name, a 32-bit big-endian length (not including the name or length), and then length more section-type-specific bytes.

The standard file extension for PFF2 font files is .pf2.

10.2.1 Section Types

FILE

File type ID (ASCII string). This must be the first section in the file. It has length 4 and the contents are the four bytes of the ASCII string ‘PFF2’.

NAME

Font name (ASCII string). This is the full font name including family, weight, style, and point size. For instance, "Helvetica Bold Italic 14".

FAMI

Font family name (ASCII string). For instance, "Helvetica". This should be included so that intelligent font substitution can take place.

WEIG

Font weight (ASCII string). Valid values are ‘bold’ and ‘normal’. This should be included so that intelligent font substitution can take place.

SLAN

Font slant (ASCII string). Valid values are ‘italic’ and ‘normal’. This should be included so that intelligent font substitution can take place.

PTSZ

Font point size (uint16be).

MAXW

Maximum character width in pixels (uint16be).

MAXH

Maximum character height in pixels (uint16be).

ASCE

Ascent in pixels (uint16be). See Font Metrics, for details.

DESC

Descent in pixels (uint16be). See Font Metrics, for details.

CHIX

Character index. The character index begins with a 32-bit big-endian unsigned integer indicating the total size of the section, not including this size value. For each character, there is an instance of the following entry structure:


Previous: File Structure, Up: PFF2 Font File Format   [Contents][Index]

10.3 Font Metrics

font_char_metrics

An illustration of how the various font metrics apply to characters.


Next: , Previous: PFF2 Font File Format, Up: Top   [Contents][Index]

11 Graphical Menu Software Design


Next: , Up: Graphical Menu Software Design   [Contents][Index]

11.1 Introduction

The ‘gfxmenu’ module provides a graphical menu interface for GRUB 2. It functions as an alternative to the menu interface provided by the ‘normal’ module, which uses the grub terminal interface to display a menu on a character-oriented terminal.

The graphical menu uses the GRUB video API, which is currently for the VESA BIOS extensions (VBE) 2.0+. This is supported on the i386-pc platform. However, the graphical menu itself does not depend on using VBE, so if another GRUB video driver were implemented, the ‘gfxmenu’ graphical menu would work on the new video driver as well.


Next: , Previous: Introduction_2, Up: Graphical Menu Software Design   [Contents][Index]

11.2 Startup Sequence


Next: , Previous: Startup Sequence, Up: Graphical Menu Software Design   [Contents][Index]

11.3 GUI Components

The graphical menu implements a GUI component system that supports a container-based layout system. Components can be added to containers, and containers (which are a type of component) can then be added to other containers, to form a tree of components. Currently, the root component of this tree is a ‘canvas’ component, which allows manual layout of its child components.

Components (non-container):

Containers:

The GUI component instances are created by the theme loader in gfxmenu/theme_loader.c when a theme is loaded. Theme files specify statements such as ‘+vbox{ +label { text="Hello" } +label{ text="World" } }’ to add components to the component tree root. By nesting the component creation statements in the theme file, the instantiated components are nested the same way.

When a component is added to a container, that new child is considered owned by the container. Great care should be taken if the caller retains a reference to the child component, since it will be destroyed if its parent container is destroyed. A better choice instead of storing a pointer to the child component is to use the component ID to find the desired component. Component IDs do not have to be unique (it is often useful to have multiple components with an ID of "__timeout__", for instance).

In order to access and use components in the component tree, there are two functions (defined in gfxmenu/gui_util.c) that are particularly useful:


Previous: GUI Components, Up: Graphical Menu Software Design   [Contents][Index]

11.4 Command Line Window

The terminal window used to provide command line access within the graphical menu is managed by gfxmenu/view.c. The ‘gfxterm’ terminal is used, and it has been modified to allow rendering to an offscreen render target to allow it to be composed into the double buffering system that the graphical menu view uses. This is bad for performance, however, so it would probably be a good idea to make it possible to temporarily disable double buffering as long as the terminal window is visible. There are still unresolved problems that occur when commands are executed from the terminal window that change the graphics mode. It’s possible that making grub_video_restore() return to the graphics mode that was in use before grub_video_setup() was called might fix some of the problems.


Next: , Previous: Graphical Menu Software Design, Up: Top   [Contents][Index]

12 Lockdown framework

The GRUB can be locked down, which is a restricted mode where some operations are not allowed. For instance, some commands cannot be used when the GRUB is locked down.

The function grub_lockdown() is used to lockdown GRUB and the function grub_is_lockdown() function can be used to check whether lockdown is enabled or not. When enabled, the function returns ‘GRUB_LOCKDOWN_ENABLED’ and ‘GRUB_LOCKDOWN_DISABLED’ when is not enabled.

The following functions can be used to register the commands that can only be used when lockdown is disabled:


Next: , Previous: Lockdown framework, Up: Top   [Contents][Index]

Appendix A Copying This Manual


Up: Copying This Manual   [Contents][Index]

A.1 GNU Free Documentation License

Version 1.2, November 2002
Copyright © 2000,2001,2002 Free Software Foundation, Inc.
51 Franklin St, Fifth Floor, Boston, MA  02110-1301, USA

Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
  1. PREAMBLE

    The purpose of this License is to make a manual, textbook, or other functional and useful document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

    This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

    We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

  2. APPLICABILITY AND DEFINITIONS

    This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

    A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

    A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

    The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

    The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

    A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”.

    Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

    The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text.

    A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition.

    The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

  3. VERBATIM COPYING

    You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

    You may also lend copies, under the same conditions stated above, and you may publicly display copies.

  4. COPYING IN QUANTITY

    If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

    If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

    If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

    It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

  5. MODIFICATIONS

    You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

    1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
    2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.
    3. State on the Title page the name of the publisher of the Modified Version, as the publisher.
    4. Preserve all the copyright notices of the Document.
    5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
    6. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
    7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license notice.
    8. Include an unaltered copy of this License.
    9. Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled “History” in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
    10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the “History” section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
    11. For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
    12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
    13. Delete any section Entitled “Endorsements”. Such a section may not be included in the Modified Version.
    14. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with any Invariant Section.
    15. Preserve any Warranty Disclaimers.

    If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.

    You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

    You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

    The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

  6. COMBINING DOCUMENTS

    You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

    The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

    In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled “History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endorsements.”

  7. COLLECTIONS OF DOCUMENTS

    You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

    You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

  8. AGGREGATION WITH INDEPENDENT WORKS

    A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

    If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

  9. TRANSLATION

    Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

    If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

  10. TERMINATION

    You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

  11. FUTURE REVISIONS OF THIS LICENSE

    The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

    Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

A.1.1 ADDENDUM: How to use this License for your documents

To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

  Copyright (C)  year  your name.
  Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.2
  or any later version published by the Free Software Foundation;
  with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
  Texts.  A copy of the license is included in the section entitled ``GNU
  Free Documentation License''.

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with...Texts.” line with this:

    with the Invariant Sections being list their titles, with
    the Front-Cover Texts being list, and with the Back-Cover Texts
    being list.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.


Previous: Copying This Manual, Up: Top   [Contents][Index]

Index

Jump to:   F  
Index Entry  Section

F
FDL, GNU Free Documentation License: GNU Free Documentation License

Jump to:   F