Linux debugging

Check our new training course

Linux debugging, tracing, profiling & perf. analysis

Check our new training course
with Creative Commons CC-BY-SA
lecture and lab materials

Bootlin logo

Elixir Cross Referencer

   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  62
  63
  64
  65
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954
 955
 956
 957
 958
 959
 960
 961
 962
 963
 964
 965
 966
 967
 968
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
\input texinfo
@c -*-texinfo-*-
@c %**start of header
@setfilename grub-dev.info
@include version-dev.texi
@settitle GNU GRUB Developers Manual @value{VERSION}
@c Unify all our little indices for now.
@syncodeindex fn cp
@syncodeindex vr cp
@syncodeindex ky cp
@syncodeindex pg cp
@syncodeindex tp cp
@c %**end of header

@footnotestyle separate
@paragraphindent 3
@finalout

@copying
This developer manual is for GNU GRUB (version @value{VERSION},
@value{UPDATED}).

Copyright @copyright{} 1999,2000,2001,2002,2004,2005,2006,2008,2009,2010,2011 Free Software Foundation, Inc.

@quotation
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.
@end quotation
@end copying

@dircategory Kernel
@direntry
* grub-dev: (grub-dev).                 The GRand Unified Bootloader Dev
@end direntry

@setchapternewpage odd

@titlepage
@sp 10
@title the GNU GRUB developer manual
@subtitle The GRand Unified Bootloader, version @value{VERSION}, @value{UPDATED}.
@author Yoshinori K. Okuji
@author Colin D Bennett
@author Vesa Jääskeläinen
@author Colin Watson
@author Robert Millan 
@author Carles Pina
@c The following two commands start the copyright page.
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage

@c Output the table of contents at the beginning.
@contents

@finalout
@headings double

@ifnottex
@node Top
@top 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 @value{VERSION}.

@insertcopying
@end ifnottex

@menu
* Getting the source code::
* Coding style::
* Finding your way around::
* Contributing Changes::
* Porting::
* Error Handling::
* Stack and heap size::
* BIOS port memory map::
* Video Subsystem::
* PFF2 Font File Format::
* Graphical Menu Software Design::
* Copying This Manual::         Copying This Manual
* Index::
@end menu


@node Getting the source code
@chapter Getting the source code

GRUB is maintained using the @uref{GIT revision
control system}.  To fetch:

@example
git clone git://git.sv.gnu.org/grub.git
@end example

Web access is available under
@example
http://git.savannah.gnu.org/cgit/grub.git/
@end example

The branches available are:

@table @samp
@item master
      Main development branch.
@item grub-legacy
      GRUB 0.97 codebase. Kept for reference and legal reasons
@item multiboot
      Multiboot specfication
@item multiboot2
      Multiboot2 specfication
@item developer branches
      Prefixed with developer name. Every developer of a team manages his own branches.
      Developer branches do not need changelog entries.
@end table

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

@node Coding style
@chapter Coding style
@c By YoshinoriOkuji, VesaJääskeläinen and ColinBennett

Basically we follow the @uref{http://www.gnu.org/prep/standards_toc.html, GNU Coding Standards}. We define additional conventions for GRUB here.

@menu
* Naming Conventions::
* Functions::
* Variables::
* Types::
* Macros::
* Comments::
* Multi-Line Comments::
@end menu

@node Naming Conventions
@section 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.

@node Functions
@section 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.

@node Variables
@section 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).

@node Types
@section 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.

@node Macros
@section 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.

@node Comments
@section Comments

All comments shall be C-style comments, of the form @samp{/* @dots{} */}.

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:
@example
/* The page # that is the front buffer.  */
int displayed_page;
/* The page # that is the back buffer.  */
int render_page;
@end example

Unacceptable:
@example
int displayed_page;           /* The page # that is the front buffer. */
int render_page;              /* The page # that is the back buffer. */
@end example

@node Multi-Line Comments
@section 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:
@example
/* This is a comment
   which spans multiple lines.
   It is long.  */
@end example

Unacceptable:
@example
/*
 * This is a comment
 * which spans multiple lines.
 * It is long. */
@end example

The opening @samp{/*} and closing @samp{*/} should be placed together on a line with text.

@node Finding your way around
@chapter 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 a Python script.  The top-level build rules are in @file{configure.ac},
@file{grub-core/Makefile.core.def}, and @file{Makefile.util.def}.  Each
block in a @file{*.def} file represents a build target, and specifies the
source files used to build it on various platforms.  The @file{*.def} files
are processed into Automake input by @file{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
@file{grub-core/Makefile.core.def} and @file{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
@file{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 @file{grub-core/boot/} directory.

The GRUB kernel is in @file{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 @file{include/}.

Terminal implementations are in @file{grub-core/term/}.

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

PCI and USB bus handling is in @file{grub-core/bus/}.

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

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

@itemize
@item
A few core commands live in @file{grub-core/kern/corecmd.c}.

@item
Commands related to normal mode live under @file{grub-core/normal/}.

@item
Commands that load and boot kernels live under @file{grub-core/loader/}.

@item
The @samp{loopback} command is really a disk device, and so lives in
@file{grub-core/disk/loopback.c}.

@item
The @samp{gettext} command lives under @file{grub-core/gettext/}.

@item
The @samp{loadfont} and @samp{lsfonts} commands live under
@file{grub-core/font/}.

@item
The @samp{serial}, @samp{terminfo}, and @samp{background_image} commands
live under @file{grub-core/term/}.

@item
The @samp{efiemu_*} commands live under @file{grub-core/efiemu/}.

@item
OS-dependent code should be under @file{grub-core/osdep/}

@item
Utility programs meant to be run from a full operating system
(except OS-dependent code mentioned previously) are in @file{util/}.

@end itemize

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

@node Contributing Changes
@chapter Contributing changes
@c By YoshinoriOkuji, VesaJääskeläinen, ColinWatson

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:
@itemize
@item @url{https://savannah.gnu.org/task/?group=grub GRUB's Task Tracker}
@item @url{https://savannah.gnu.org/bugs/?group=grub GRUB's Bug Tracker}
@end itemize

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

@menu
* Getting started::
* Typical Developer Experience::
* When you are approved for write access to project's files::
@end menu

@node Getting started
@section Getting started

@itemize
@item Always use latest GRUB 2 source code. So get that first.

For developers it is recommended always to use the newest development version of GRUB 2. If development takes a long period of time, please remember to keep in sync with newest developments regularly so it is much easier to integrate your change in the future. GRUB 2 is being developed in a GIT repository.

Please check Savannah's GRUB project page for details how to get newest git:
@uref{https://savannah.gnu.org/git/?group=grub, GRUB 2 git Repository}

@item Compile it and try it out.

It is always good idea to first see that things work somehow and after that
to start to implement new features or develop fixes to bugs.

@item Study the code.

There are sometimes odd ways to do things in GRUB 2 code base.
This is mainly related to limited environment where GRUB 2 is being executed.
You usually do not need to understand it all so it is better to only try to
look at places that relates to your work. Please do not hesitate to ask for
help if there is something that you do not understand.

@item Develop a new feature.

Now that you know what to do and how it should work in GRUB 2 code base, please
be free to develop it. If you have not so far announced your idea on grub-devel
mailing list, please do it now. This is to make sure you are not wasting your
time working on the solution that will not be integrated to GRUB 2 code base.

You might want to study our coding style before starting development so you
do not need to change much of the code when your patch is being reviewed.
(see @ref{Coding style})

For every accepted patch there has to exist a ChangeLog entry. Our ChangeLog
consist of changes within source code and are not describing about what the
change logically does. Please see examples from previous entries.

Also remember that GRUB 2 is licensed under GPLv3 license and that usually
means that you are not allowed to copy pieces of code from other projects.
Even if the source project's license would be compatible with GPLv3, please
discuss it beforehand on grub-devel mailing list.

@item Test your change.

Test that your change works properly. Try it out a couple of times, preferably on different systems, and try to find problems with it.

@item Publish your change.

When you are happy with your change, first make sure it is compilable with
latest development version of GRUB 2. After that please send a patch to
grub-devel for review. Please describe in your email why you made the change,
what it changes and so on. Please be prepared to receive even discouraging
comments about your patch. There is usually at least something that needs
to be improved in every patch.

Please use unified diff to make your patch (good match of arguments for diff is @samp{-pruN}).

@item Respond to received feedback.

If you are asked to modify your patch, please do that and resubmit it for
review. If your change is large you are required to submit a copyright
agreement to FSF. Please keep in mind that if you are asked to submit
for copyright agreement, process can take some time and is mandatory
in order to get your changes integrated.

If you are not on grub-devel to respond to questions, most likely your patch
will not be accepted. Also if problems arise from your changes later on,
it would be preferable that you also fix the problem. So stay around
for a while.

@item Your patch is accepted.

Good job! Your patch will now be integrated into GRUB 2 mainline, and if it didn't break anything it will be publicly available in the next release.

Now you are welcome to do further improvements :)
@end itemize

@node Typical Developer Experience
@section Typical Developer Experience

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

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

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.

@node When you are approved for write access to project's files
@section When you are approved for write access to project's files

As you might know, GRUB is hosted on
@url{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:

@enumerate
@item You need to create your own account on Savannah.
@item You can submit ``Request for Inclusion'' from ``My Groups'' on Savannah.
@end enumerate

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...).

@node Porting
@chapter 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)

@example
        .globl _start
_start:
	movl	$_bss_start, %edi
	movl	$_end, %ecx
	subl	%edi, %ecx
	xorl	%eax, %eax
	cld
	rep
	stosb
        call main
@end example

@example

static const char msg[] = "Hello, world";

void
putchar (int c)
@{
  ...
@}

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

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:

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

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.

@example
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
@end example

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:

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

Add your platform to the list of supported ones:

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

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

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

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

@example
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])
@end example

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

@example
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" ]
@end example

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:

@example
#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 */
@end example

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:

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

And create image

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

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:

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

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:
@itemize
@item Is heap big enough?
@item Which charset is supported by console?
@item Does platform have disk driver?
@item Do you have network card support?
@item Are you able to retrieve datetime (with date)?
@item Are you able to set datetime (with date)?
@item Is serial supported?
@item Do you have direct disk support?
@item Do you have direct keyboard support?
@item Do you have USB support?
@item Do you support loading through network?
@item Do you support loading from disk?
@item Do you support chainloading?
@item Do you support network chainloading?
@item Does cpuid command supports checking all
CPU features that the user might want conditionalise on
(64-bit mode, hypervisor,...)
@item Do you support hints? How reliable are they?
@item Does platform have ACPI? If so do ``acpi'' and ``lsacpi'' modules work?
@item Do any of platform-specific operations mentioned in the relevant section of
user manual makes sense on your platform?
@item Does your platform support PCI? If so is there an appropriate driver for
GRUB?
@item Do you support badram?
@end itemize

@node Error Handling
@chapter 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 @code{grub_errno} global variable. If
@code{grub_errno} variable contains value @code{GRUB_ERR_NONE}, there is no active
exception and application can continue normal processing. When @code{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 @code{grub_err_t} is
about to return @code{GRUB_ERR_NONE}, it should not set @code{grub_errno} to that
value. Only set @code{grub_errno} in cases where there is error situation. 

Simple exception forwarder.
@example
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;
@}
@end example

Error reporting has two components, the actual error code (of type
@code{grub_err_t}) and textual message that will be displayed to user. List of
valid error codes is listed in header file @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 @code{grub_error} that allows easier
formatting of error messages and should be used instead of writing directly to
global variables.

Example of error reporting.
@example
grub_err_t
failing_example ()
@{
  return grub_error (GRUB_ERR_FILE_NOT_FOUND, 
                     "Failed to read %s, tried %d times.",
                     "test.txt",
                     10);
@}
@end example

If there is a special reason that error code does not need to be taken account,
@code{grub_errno} can be zeroed back to @code{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 @code{grub_errno}.
@example
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.");
@}
@end example

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 @code{grub_error_push ()}. When processing has been completed,
@code{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.
@example
/* 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 ();
@end example

@node Stack and heap size
@chapter 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:

@multitable @columnfractions .15 .25 .5
@headitem Platform @tab Stack @tab Heap
@item emu                     @tab 8 MiB   @tab ?
@item i386-pc                 @tab 60 KiB  @tab < 4 GiB
@item i386-coreboot           @tab 60 KiB  @tab < 4 GiB
@item i386-multiboot          @tab 60 KiB  @tab < 4 GiB
@item i386-qemu               @tab 60 KiB  @tab < 4 GiB
@item *-efi                   @tab ?       @tab < 1.6 GiB
@item i386-ieee1275           @tab ?       @tab < 32 MiB
@item powerpc-ieee1275        @tab ?       @tab < 32 MiB
@item sparc64-ieee1275        @tab 256KiB  @tab 2 MiB
@item arm-uboot               @tab 256KiB  @tab 2 MiB
@item mips(el)-qemu_mips      @tab 2MiB    @tab 253 MiB
@item mipsel-loongson         @tab 2MiB    @tab 253 MiB
@item mips-arc                @tab 2MiB    @tab 125 MiB
@item mipsel-arc              @tab 2MiB    @tab 248 MiB
@item x86_64-xen (GCC >= 4.4) @tab 4MiB    @tab unlimited
@item x86_64-xen (GCC < 4.4)  @tab 4MiB    @tab < 2GiB
@item i386-xen                @tab 4MiB    @tab < 4GiB
@end multitable


@node BIOS port memory map
@chapter BIOS port memory map
@c By Yoshinori K Okuji

@multitable @columnfractions .15 .25 .5
@headitem Start @tab End @tab Usage
@item 0        @tab 0x1000 - 1   @tab BIOS and real mode interrupts 
@item 0x07BE   @tab 0x07FF       @tab Partition table passed to another boot loader 
@item ?        @tab 0x2000 - 1   @tab Real mode stack 
@item 0x7C00   @tab 0x7D00 - 1   @tab Boot sector 
@item 0x8000   @tab ?            @tab GRUB kernel 
@item 0x68000  @tab 0x71000 - 1  @tab Disk buffer 
@item ?        @tab 0x80000 - 1  @tab Protected mode stack 
@item ?        @tab 0xA0000 - 1  @tab Extended BIOS Data Area 
@item 0xA0000  @tab 0xC0000 - 1  @tab Video RAM 
@item 0xC0000  @tab 0x100000 - 1 @tab BIOS 
@item 0x100000 @tab ?            @tab Heap and module code 
@end multitable

@node Video Subsystem
@chapter Video Subsystem
@c By VesaJääskeläinen
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.

@menu
* Video API::
* Example usage of Video API::
* Bitmap API::
@end menu

@node Video API
@section Video API

@subsection grub_video_setup

@itemize
@item Prototype:
@example
grub_err_t
grub_video_setup (unsigned int width, unsigned int height, unsigned int mode_type);
@end example
@item Description:

Driver will use information provided to it to select best possible video mode and switch to it. Supported values for @code{mode_type} are @code{GRUB_VIDEO_MODE_TYPE_INDEX_COLOR} for index color modes, @code{GRUB_VIDEO_MODE_TYPE_RGB} for direct RGB color modes and @code{GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED} for double buffering. When requesting RGB mode, highest bits per pixel mode will be selected. When requesting Index color mode, mode with highest number of colors will be selected. If all parameters are specified as zero, video adapter will try to figure out best possible mode and initialize it, platform specific differences are allowed here. If there is no mode matching request, error X will be returned. If there are no problems, function returns @code{GRUB_ERR_NONE}.

This function also performs following task upon succesful mode switch. Active rendering target is changed to screen and viewport is maximized to allow whole screen to be used when performing graphics operations. In RGB modes, emulated palette gets 16 entries containing default values for VGA palette, other colors are defined as black. When switching to Indexed Color mode, driver may set default VGA palette to screen if the video card allows the operation.

@end itemize

@subsection grub_video_restore
@itemize
@item Prototype:

@example
grub_err_t
grub_video_restore (void);
@end example
@item Description:

Video subsystem will deinitialize activated video driver to restore old state of video device. This can be used to switch back to text mode.
@end itemize

@subsection grub_video_get_info
@itemize
@item Prototype:

@example
grub_err_t
grub_video_get_info (struct grub_video_mode_info *mode_info);
@end example
@example
struct grub_video_mode_info
@{
  /* Width of the screen.  */
  unsigned int width;
  /* Height of the screen.  */
  unsigned int height;
  /* Mode type bitmask.  Contains information like is it Index color or
     RGB mode.  */
  unsigned int mode_type;
  /* Bits per pixel.  */
  unsigned int bpp;
  /* Bytes per pixel.  */
  unsigned int bytes_per_pixel;
  /* Pitch of one scanline.  How many bytes there are for scanline.  */
  unsigned int pitch;
  /* In index color mode, number of colors.  In RGB mode this is 256.  */
  unsigned int number_of_colors;
  /* Optimization hint how binary data is coded.  */
  enum grub_video_blit_format blit_format;
  /* How many bits are reserved for red color.  */
  unsigned int red_mask_size;
  /* What is location of red color bits.  In Index Color mode, this is 0.  */
  unsigned int red_field_pos;
  /* How many bits are reserved for green color.  */
  unsigned int green_mask_size;
  /* What is location of green color bits.  In Index Color mode, this is 0.  */
  unsigned int green_field_pos;
  /* How many bits are reserved for blue color.  */
  unsigned int blue_mask_size;
  /* What is location of blue color bits.  In Index Color mode, this is 0.  */
  unsigned int blue_field_pos;
  /* How many bits are reserved in color.  */
  unsigned int reserved_mask_size;
  /* What is location of reserved color bits.  In Index Color mode,
     this is 0.  */
  unsigned int reserved_field_pos;
@};
@end example
@item Description:

Software developer can use this function to query properties of active rendering taget. Information provided here can be used by other parts of GRUB, like image loaders to convert loaded images to correct screen format to allow more optimized blitters to be used. If there there is no configured video driver with active screen, error @code{GRUB_ERR_BAD_DEVICE} is returned, otherwise @code{mode_info} is filled with valid information and @code{GRUB_ERR_NONE} is returned.
@end itemize

@subsection grub_video_get_blit_format
@itemize
@item Prototype:

@example
enum grub_video_blit_format
grub_video_get_blit_format (struct grub_video_mode_info *mode_info);
@end example
@example
enum grub_video_blit_format
  @{
    /* Follow exactly field & mask information.  */
    GRUB_VIDEO_BLIT_FORMAT_RGBA,
    /* Make optimization assumption.  */
    GRUB_VIDEO_BLIT_FORMAT_R8G8B8A8,
    /* Follow exactly field & mask information.  */
    GRUB_VIDEO_BLIT_FORMAT_RGB,
    /* Make optimization assumption.  */
    GRUB_VIDEO_BLIT_FORMAT_R8G8B8,
    /* When needed, decode color or just use value as is.  */
    GRUB_VIDEO_BLIT_FORMAT_INDEXCOLOR
  @};
@end example
@item Description:

Used to query how data could be optimized to suit specified video mode. Returns exact video format type, or a generic one if there is no definition for the type. For generic formats, use @code{grub_video_get_info} to query video color coding settings.
@end itemize

@subsection grub_video_set_palette
@itemize
@item Prototype:

@example
grub_err_t
grub_video_set_palette (unsigned int start, unsigned int count, struct grub_video_palette_data *palette_data);
@end example
@example
struct grub_video_palette_data
@{
    grub_uint8_t r; /* Red color value (0-255). */
    grub_uint8_t g; /* Green color value (0-255). */
    grub_uint8_t b; /* Blue color value (0-255). */
    grub_uint8_t a; /* Reserved bits value (0-255). */
@};
@end example
@item Description:

Used to setup indexed color palettes. If mode is RGB mode, colors will be set to emulated palette data. In Indexed Color modes, palettes will be set to hardware. Color values will be converted to suit requirements of the video mode. @code{start} will tell what hardware color index (or emulated color index) will be set to according information in first indice of @code{palette_data}, after that both hardware color index and @code{palette_data} index will be incremented until @code{count} number of colors have been set.
@end itemize

@subsection grub_video_get_palette
@itemize
@item Prototype:

@example
grub_err_t
grub_video_get_palette (unsigned int start, unsigned int count, struct grub_video_palette_data *palette_data);
@end example
@example
struct grub_video_palette_data
@{
    grub_uint8_t r; /* Red color value (0-255). */
    grub_uint8_t g; /* Green color value (0-255). */
    grub_uint8_t b; /* Blue color value (0-255). */
    grub_uint8_t a; /* Reserved bits value (0-255). */
@};
@end example
@item Description:

Used to query indexed color palettes. If mode is RGB mode, colors will be copied from emulated palette data. In Indexed Color modes, palettes will be read from hardware. Color values will be converted to suit structure format. @code{start} will tell what hardware color index (or emulated color index) will be used as a source for first indice of @code{palette_data}, after that both hardware color index and @code{palette_data} index will be incremented until @code{count} number of colors have been read.
@end itemize

@subsection grub_video_set_area_status
@itemize

@item Prototype:
@example
grub_err_t
grub_video_set_area_status (grub_video_area_status_t area_status);
@end example
@example
enum grub_video_area_status_t
  @{
    GRUB_VIDEO_AREA_DISABLED,
    GRUB_VIDEO_AREA_ENABLED
  @};
@end example

@item Description:

Used to set area drawing mode for redrawing the specified region. Draw commands
are performed in the intersection of the viewport and the region called area.
Coordinates remain related to the viewport. If draw commands try to draw over
the area, they are clipped.
Set status to DISABLED if you need to draw everything.
Set status to ENABLED and region to the desired rectangle to redraw everything
inside the region leaving everything else intact.
Should be used for redrawing of active elements.
@end itemize

@subsection grub_video_get_area_status
@itemize

@item Prototype:
@example
grub_err_r
grub_video_get_area_status (grub_video_area_status_t *area_status);
@end example

@item Description:
Used to query the area status.
@end itemize

@subsection grub_video_set_viewport
@itemize
@item Prototype:

@example
grub_err_t
grub_video_set_viewport (unsigned int x, unsigned int y, unsigned int width, unsigned int height);
@end example
@item Description:

Used to specify viewport where draw commands are performed. When viewport is set, all draw commands coordinates relate to those specified by @code{x} and @code{y}. If draw commands try to draw over viewport, they are clipped. If developer requests larger than possible viewport, width and height will be clamped to fit screen. If @code{x} and @code{y} are out of bounds, all functions drawing to screen will not be displayed. In order to maximize viewport, use @code{grub_video_get_info} to query actual screen dimensions and provide that information to this function.
@end itemize

@subsection grub_video_get_viewport
@itemize
@item Prototype:

@example
grub_err_t
grub_video_get_viewport (unsigned int *x, unsigned int *y, unsigned int *width, unsigned int *height);
@end example
@item Description:

Used to query current viewport dimensions. Software developer can use this to choose best way to render contents of the viewport.
@end itemize

@subsection grub_video_set_region
@itemize
@item Prototype:

@example
grub_err_t
grub_video_set_region (unsigned int x, unsigned int y, unsigned int width, unsigned int height);
@end example
@item Description:

Used to specify the region of the screen which should be redrawn. Use absolute
values. When the region is set and area status is ENABLE all draw commands will
be performed inside the interseption of region and viewport named area.
If draw commands try to draw over viewport, they are clipped. If developer
requests larger than possible region, width and height will be clamped to fit
screen. Should be used for redrawing of active elements.
@end itemize

@subsection grub_video_get_region
@itemize
@item Prototype:

@example
grub_err_t
grub_video_get_region (unsigned int *x, unsigned int *y, unsigned int *width, unsigned int *height);
@end example
@item Description:

Used to query current region dimensions.
@end itemize

@subsection grub_video_map_color
@itemize
@item Prototype:

@example
grub_video_color_t
grub_video_map_color (grub_uint32_t color_name);
@end example
@item Description:

Map color can be used to support color themes in GRUB. There will be collection of color names that can be used to query actual screen mapped color data. Examples could be @code{GRUB_COLOR_CONSOLE_BACKGROUND}, @code{GRUB_COLOR_CONSOLE_TEXT}. The actual color defines are not specified at this point.
@end itemize

@subsection grub_video_map_rgb
@itemize
@item Prototype:

@example
grub_video_color_t
grub_video_map_rgb (grub_uint8_t red, grub_uint8_t green, grub_uint8_t blue);
@end example
@item Description:

Map RGB values to compatible screen color data. Values are expected to be in range 0-255 and in RGB modes they will be converted to screen color data. In index color modes, index color palette will be searched for specified color and then index is returned.
@end itemize

@subsection grub_video_map_rgba
@itemize
@item Prototype:

@example
grub_video_color_t
grub_video_map_rgba (grub_uint8_t red, grub_uint8_t green, grub_uint8_t blue, grub_uint8_t alpha);
@end example
@item Description:

Map RGBA values to compatible screen color data. Values are expected to be in range 0-255. In RGBA modes they will be converted to screen color data. In index color modes, index color palette will be searched for best matching color and its index is returned.
@end itemize

@subsection grub_video_unmap_color
@itemize
@item Prototype:

@example
grub_err_t
grub_video_unmap_color (grub_video_color_t color, grub_uint8_t *red, grub_uint8_t *green, grub_uint8_t *blue, grub_uint8_t *alpha);
@end example
@item Description:

Unmap color value from @code{color} to color channels in @code{red}, @code{green}, @code{blue} and @code{alpha}. Values will be in range 0-255. Active rendering target will be used for color domain. In case alpha information is not available in rendering target, it is assumed to be opaque (having value 255).
@end itemize

@subsection grub_video_fill_rect
@itemize
@item Prototype:

@example
grub_err_t
grub_video_fill_rect (grub_video_color_t color, int x, int y, unsigned int width, unsigned int height);
@end example
@item Description:

Fill specified area limited by given coordinates within specified viewport. Negative coordinates are accepted in order to allow easy moving of rectangle within viewport. If coordinates are negative, area of the rectangle will be shrinken to follow size limits of the viewport.

Software developer should use either @code{grub_video_map_color}, @code{grub_video_map_rgb} or @code{grub_video_map_rgba} to map requested color to @code{color} parameter.
@end itemize

@subsection grub_video_blit_glyph
@itemize
@item Prototype:

@example
grub_err_t
grub_video_blit_glyph (struct grub_font_glyph *glyph, grub_video_color_t color, int x, int y);
@end example
@example
struct grub_font_glyph @{
    /* TBD. */
@};
@end example
@item Description:

Used to blit glyph to viewport in specified coodinates. If glyph is at edge of viewport, pixels outside of viewport will be clipped out. Software developer should use either @code{grub_video_map_rgb} or @code{grub_video_map_rgba} to map requested color to @code{color} parameter.
@end itemize

@subsection grub_video_blit_bitmap
@itemize
@item Prototype:

@example
grub_err_t
grub_video_blit_bitmap (struct grub_video_bitmap *bitmap, enum grub_video_blit_operators oper, int x, int y, int offset_x, int offset_y, unsigned int width, unsigned int height);
@end example
@example
struct grub_video_bitmap
@{
    /* TBD. */
@};

enum grub_video_blit_operators
  @{
    GRUB_VIDEO_BLIT_REPLACE,
    GRUB_VIDEO_BLIT_BLEND
  @};
@end example
@item Description:

Used to blit bitmap to viewport in specified coordinates. If part of bitmap is outside of viewport region, it will be clipped out. Offsets affect bitmap position where data will be copied from. Negative values for both viewport coordinates and bitmap offset coordinates are allowed. If data is looked out of bounds of bitmap, color value will be assumed to be transparent. If viewport coordinates are negative, area of the blitted rectangle will be shrinken to follow size limits of the viewport and bitmap. Blitting operator @code{oper} specifies should source pixel replace data in screen or blend with pixel alpha value.

Software developer should use @code{grub_video_bitmap_create} or @code{grub_video_bitmap_load} to create or load bitmap data.
@end itemize

@subsection grub_video_blit_render_target
@itemize
@item Prototype:

@example
grub_err_t
grub_video_blit_render_target (struct grub_video_render_target *source, enum grub_video_blit_operators oper, int x, int y, int offset_x, int offset_y, unsigned int width, unsigned int height);
@end example
@example
struct grub_video_render_target @{
    /* This is private data for video driver. Should not be accessed from elsewhere directly.  */
@};

enum grub_video_blit_operators
  @{
    GRUB_VIDEO_BLIT_REPLACE,
    GRUB_VIDEO_BLIT_BLEND
  @};
@end example
@item Description:

Used to blit source render target to viewport in specified coordinates. If part of source render target is outside of viewport region, it will be clipped out. If blitting operator is specified and source contains alpha values, resulting pixel color components will be calculated using formula ((src_color * src_alpha) + (dst_color * (255 - src_alpha)) / 255, if target buffer has alpha, it will be set to src_alpha. Offsets affect render target position where data will be copied from. If data is looked out of bounds of render target, color value will be assumed to be transparent. Blitting operator @code{oper} specifies should source pixel replace data in screen or blend with pixel alpha value.
@end itemize

@subsection grub_video_scroll
@itemize
@item Prototype:

@example
grub_err_t
grub_video_scroll (grub_video_color_t color, int dx, int dy);
@end example
@item Description:

Used to scroll viewport to specified direction. New areas are filled with specified color. This function is used when screen is scroller up in video terminal.
@end itemize

@subsection grub_video_swap_buffers
@itemize
@item Prototype:

@example
grub_err_t
grub_video_swap_buffers (void);
@end example
@item Description:

If double buffering is enabled, this swaps frontbuffer and backbuffer, in order to show values drawn to back buffer. Video driver is free to choose how this operation is techincally done.
@end itemize

@subsection grub_video_create_render_target
@itemize
@item Prototype:

@example
grub_err_t
grub_video_create_render_target (struct grub_video_render_target **result, unsigned int width, unsigned int height, unsigned int mode_type);
@end example
@example
struct grub_video_render_target @{
    /* This is private data for video driver. Should not be accessed from elsewhere directly.  */
@};
@end example
@item Description:

Driver will use information provided to it to create best fitting render target. @code{mode_type} will be used to guide on selecting what features are wanted for render target. Supported values for @code{mode_type} are @code{GRUB_VIDEO_MODE_TYPE_INDEX_COLOR} for index color modes, @code{GRUB_VIDEO_MODE_TYPE_RGB} for direct RGB color modes and @code{GRUB_VIDEO_MODE_TYPE_ALPHA} for alpha component.
@end itemize

@subsection grub_video_delete_render_target
@itemize
@item Prototype:

@example
grub_err_t
grub_video_delete_render_target (struct grub_video_render_target *target);
@end example
@item Description:

Used to delete previously created render target. If @code{target} contains @code{NULL} pointer, nothing will be done. If render target is correctly destroyed, GRUB_ERR_NONE is returned.
@end itemize

@subsection grub_video_set_active_render_target
@itemize
@item Prototype:

@example
grub_err_t
grub_video_set_active_render_target (struct grub_video_render_target *target);
@end example
@item Description:

Sets active render target. If this comand is successful all drawing commands will be done to specified @code{target}. There is also special values for target, @code{GRUB_VIDEO_RENDER_TARGET_DISPLAY} used to reference screen's front buffer, @code{GRUB_VIDEO_RENDER_TARGET_FRONT_BUFFER} used to reference screen's front buffer (alias for @code{GRUB_VIDEO_RENDER_TARGET_DISPLAY}) and @code{GRUB_VIDEO_RENDER_TARGET_BACK_BUFFER} used to reference back buffer (if double buffering is enabled). If render target is correclty switched GRUB_ERR_NONE is returned. In no any event shall there be non drawable active render target.

@end itemize
@subsection grub_video_get_active_render_target
@itemize
@item Prototype:

@example
grub_err_t
grub_video_get_active_render_target (struct grub_video_render_target **target);
@end example
@item Description:

Returns currently active render target. It returns value in @code{target} that can be subsequently issued back to @code{grub_video_set_active_render_target}.
@end itemize

@node Example usage of Video API
@section Example usage of Video API
@subsection Example of screen setup
@example
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.  */
  @}
@}
@end example
@subsection Example of setting up console viewport
@example
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);
@end example

@node Bitmap API
@section Bitmap API
@subsection grub_video_bitmap_create
@itemize
@item Prototype:
@example
grub_err_t grub_video_bitmap_create (struct grub_video_bitmap **bitmap, unsigned int width, unsigned int height, enum grub_video_blit_format blit_format)
@end example

@item Description:

Creates a new bitmap with given dimensions and blitting format. Allocated bitmap data can then be modified freely and finally blitted with @code{grub_video_blit_bitmap} to rendering target.
@end itemize

@subsection grub_video_bitmap_destroy
@itemize
@item Prototype:
@example
grub_err_t grub_video_bitmap_destroy (struct grub_video_bitmap *bitmap);
@end example

@item Description:

When bitmap is no longer needed, it can be freed from memory using this command. @code{bitmap} is previously allocated bitmap with @code{grub_video_bitmap_create} or loaded with @code{grub_video_bitmap_load}.
@end itemize

@subsection grub_video_bitmap_load
@itemize
@item Prototype:
@example
grub_err_t grub_video_bitmap_load (struct grub_video_bitmap **bitmap, const char *filename);
@end example

@item Description:

Tries to load given bitmap (@code{filename}) using registered bitmap loaders. In case bitmap format is not recognized or supported error @code{GRUB_ERR_BAD_FILE_TYPE} is returned.
@end itemize

@subsection grub_video_bitmap_get_width
@itemize
@item Prototype:
@example
unsigned int grub_video_bitmap_get_width (struct grub_video_bitmap *bitmap);
@end example

@item Description:

Returns bitmap width.
@end itemize

@subsection grub_video_bitmap_get_height
@itemize
@item Prototype:
@example
unsigned int grub_video_bitmap_get_height (struct grub_video_bitmap *bitmap);
@end example

@item Description:

Return bitmap height.
@end itemize

@subsection grub_video_bitmap_get_mode_info
@itemize
@item Prototype:
@example
void grub_video_bitmap_get_mode_info (struct grub_video_bitmap *bitmap, struct grub_video_mode_info *mode_info);
@end example

@item Description:

Returns bitmap format details in form of @code{grub_video_mode_info}.
@end itemize

@subsection grub_video_bitmap_get_data
@itemize
@item Prototype:
@example
void *grub_video_bitmap_get_data (struct grub_video_bitmap *bitmap);
@end example

@item Description:

Return pointer to bitmap data. Contents of the pointed data can be freely modified. There is no extra protection against going off the bounds so you have to be carefull how to access the data.
@end itemize

@node PFF2 Font File Format
@chapter PFF2 Font File Format

@c Author: Colin D. Bennett <colin@gibibit.com>
@c Date: 8 January 2009

@menu
* Introduction::
* File Structure::
* Font Metrics::
@end menu


@node Introduction
@section Introduction

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


@subsection Goals of the GRUB Font Format

@itemize
@item Simple to read and use.
Since GRUB will only be reading the font files,
we are more concerned with making the code to read the font simple than we
are with writing the font.

@item Compact storage.
The fonts will generally be stored in a small boot
partition where GRUB is located, and this may be on a removable storage
device such as a CD or USB flash drive where space is more limited than it
is on most hard drives.

@item Unicode.
GRUB should not have to deal with multiple character
encodings.  The font should always use Unicode character codes for simple
internationalization.
@end itemize

@subsection 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:

@table @samp
@item BDF 
Inefficient storage; uses ASCII to describe properties and 
hexadecimal numbers in ASCII for the bitmap rows.
@item 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.
@end table

@node File Structure
@section File Structure

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

The standard file extension for PFF2 font files is @file{.pf2}.


@subsection Section Types

@table @samp
@item FILE
@strong{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 @samp{PFF2}.

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

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

@item WEIG
@strong{Font weight} (ASCII string).  Valid values are @samp{bold} and @samp{normal}.
This should be included so that intelligent font substitution can take
place.

@item SLAN
@strong{Font slant} (ASCII string).  Valid values are @samp{italic} and @samp{normal}.
This should be included so that intelligent font substitution can take
place.

@item PTSZ
@strong{Font point size} (uint16be).

@item MAXW
@strong{Maximum character width in pixels} (uint16be).

@item MAXH
@strong{Maximum character height in pixels} (uint16be).

@item ASCE
@strong{Ascent in pixels} (uint16be).  @xref{Font Metrics}, for details.

@item DESC
@strong{Descent in pixels} (uint16be).  @xref{Font Metrics}, for details.

@item CHIX
@strong{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:

@itemize
@item @strong{Unicode code point.} (32-bit big-endian integer.)

@item @strong{Storage flags.} (byte.)
       
@itemize
@item Bits 2..0: 

If equal to 000 binary, then the character data is stored
uncompressed beginning at the offset indicated by the character's
@strong{offset} value.

If equal to 001 binary, then the character data is stored within a 
compressed character definition block that begins at the offset 
within the file indicated by the character's @strong{offset} value.
@end itemize

@item @strong{Offset.} (32-bit big-endian integer.)

A marker that indicates the remainder of the file is data accessed via
the character index (CHIX) section.  When reading this font file, the rest
of the file can be ignored when scanning the sections.  The length should
be set to -1 (0xFFFFFFFF).

Supported data structures:

Character definition
Each character definition consists of:

@itemize
@item @strong{Width.}
Width of the bitmap in pixels.  The bitmap's extents 
represent the glyph's bounding box.  @code{uint16be}.

@item @strong{Height.}
Height of the bitmap in pixels.  The bitmap's extents
represent the glyph's bounding box.  @code{uint16be}.

@item @strong{X offset.}
The number of pixels to shift the bitmap by
horizontally before drawing the character. @code{int16be}.

@item @strong{Y offset.}
The number of pixels to shift the bitmap by
vertically before drawing the character. @code{int16be}.

@item @strong{Device width.}
The number of pixels to advance horizontally from
this character's origin to the origin of the next character.
@code{int16be}.

@item @strong{Bitmap data.}
This is encoded as a string of bits.  It is
organized as a row-major, top-down, left-to-right bitmap.  The most
significant bit of each byte is taken to be the leftmost or uppermost
bit in the byte.  For the sake of compact storage, rows are not padded
to byte boundaries (i.e., a single byte may contain bits belonging to
multiple rows).  The last byte of the bitmap @strong{is} padded with zero
bits in the bits positions to the right of the last used bit if the
bitmap data does not fill the last byte.  
         
The length of the @strong{bitmap data} field is (@var{width} * @var{height} + 7) / 8
using integer arithmetic, which is equivalent to ceil(@var{width} *
@var{height} / 8) using real number arithmetic.

It remains to be determined whether bitmap fonts usually make all
glyph bitmaps the same height, or if smaller glyphs are stored with
bitmaps having a lesser height.  In the latter case, the baseline
would have to be used to calculate the location the bitmap should be
anchored at on screen.
@end itemize

@end itemize
@end table

@node Font Metrics
@section Font Metrics

@itemize
@item Ascent.
The distance from the baseline to the top of most characters.
Note that in some cases characters may extend above the ascent.

@item Descent.
The distance from the baseline to the bottom of most characters.  Note that
in some cases characters may extend below the descent.
 
@item Leading.
The amount of space, in pixels, to leave between the descent of one line of
text and the ascent of the next line.  This metrics is not specified in the
current file format; instead, the font rendering engine calculates a
reasonable leading value based on the other font metrics.

@item Horizonal leading.
The amount of space, in pixels, to leave horizontally between the left and
right edges of two adjacent glyphs.  The @strong{device width} field determines
the effective leading value that is used to render the font.

@end itemize
@ifnottex
@image{font_char_metrics,,,,.png}
@end ifnottex
   
An illustration of how the various font metrics apply to characters.



@node Graphical Menu Software Design
@chapter Graphical Menu Software Design

@c By Colin D. Bennett <colin@gibibit.com>
@c Date: 17 August 2008

@menu
* Introduction_2::
* Startup Sequence::
* GUI Components::
* Command Line Window::
@end menu

@node Introduction_2
@section Introduction

The @samp{gfxmenu} module provides a graphical menu interface for GRUB 2.  It
functions as an alternative to the menu interface provided by the @samp{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 @samp{gfxmenu} graphical menu would work
on the new video driver as well.


@node Startup Sequence
@section Startup Sequence

@itemize
@item grub_enter_normal_mode [normal/main.c]
@item grub_normal_execute [normal/main.c]
@item read_config_file [normal/main.c]
@item (When @file{gfxmenu.mod} is loaded with @command{insmod}, it will call @code{grub_menu_viewer_register()} to register itself.)
@item GRUB_MOD_INIT (gfxmenu) [gfxmenu/gfxmenu.c]
@item grub_menu_viewer_register [kern/menu_viewer.c]
@item grub_menu_viewer_show_menu [kern/menu_viewer.c]
@item get_current_menu_viewer() [kern/menu_viewer.c]
@item show_menu() [gfxmenu/gfxmenu.c]
@item grub_gfxmenu_model_new [gfxmenu/model.c]
@item grub_gfxmenu_view_new [gfxmenu/view.c]
@item set_graphics_mode [gfxmenu/view.c]
@item grub_gfxmenu_view_load_theme [gfxmenu/theme_loader.c]
@end itemize


@node GUI Components
@section 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 @samp{canvas} component, which allows manual layout of its child
components.

Components (non-container):

@itemize
@item label
@item image
@item progress_bar
@item circular_progress
@item list (currently hard coded to be a boot menu list)
@end itemize

Containers:

@itemize
@item canvas
@item hbox
@item vbox
@end itemize

The GUI component instances are created by the theme loader in
@file{gfxmenu/theme_loader.c} when a theme is loaded.  Theme files specify
statements such as @samp{+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 @strong{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 @file{gfxmenu/gui_util.c}) that are particularly useful:

@itemize

@item @code{grub_gui_find_by_id (root, id, callback, userdata)}:

This function ecursively traverses the component tree rooted at @var{root}, and
for every component that has an ID equal to @var{id}, calls the function pointed
to by @var{callback} with the matching component and the void pointer @var{userdata}
as arguments.  The callback function can do whatever is desired to use the
component passed in.

@item @code{grub_gui_iterate_recursively (root, callback, userdata)}:

This function calls the function pointed to by @var{callback} for every
component that is a descendant of @var{root} in the component tree.  When the
callback function is called, the component and the void pointer @var{userdata}
as arguments.  The callback function can do whatever is desired to use the
component passed in.
@end itemize

@node Command Line Window
@section Command Line Window

The terminal window used to provide command line access within the graphical
menu is managed by @file{gfxmenu/view.c}.  The @samp{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 @code{grub_video_restore()} return to
the graphics mode that was in use before @code{grub_video_setup()} was called
might fix some of the problems.


@node Copying This Manual
@appendix Copying This Manual

@menu
* GNU Free Documentation License::  License for copying this manual.
@end menu

@include fdl.texi


@node Index
@unnumbered Index

@c Currently, we use only the Concept Index.
@printindex cp

@bye