## @file
|
# Ext4 Package
|
#
|
# UEFI Driver that produces the Simple File System Protocol for a partition that is formatted
|
# with the EXT4 file system.
|
# More details are available at: https://www.kernel.org/doc/html/v5.4/filesystems/ext4/index.html
|
#
|
# Copyright (c) 2021 Pedro Falcato
|
# SPDX-License-Identifier: BSD-2-Clause-Patent
|
#
|
# Layout of an EXT2/3/4 filesystem:
|
# (note: this driver has been developed using
|
# https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html as
|
# documentation).
|
#
|
# An ext2/3/4 filesystem (here on out referred to as simply an ext4 filesystem,
|
# due to the similarities) is composed of various concepts:
|
#
|
# 1) Superblock
|
# The superblock is the structure near (1024 bytes offset from the start)
|
# the start of the partition, and describes the filesystem in general.
|
# Here, we get to know the size of the filesystem's blocks, which features
|
# it supports or not, whether it's been cleanly unmounted, how many blocks
|
# we have, etc.
|
#
|
# 2) Block groups
|
# EXT4 filesystems are divided into block groups, and each block group covers
|
# s_blocks_per_group(8 * Block Size) blocks. Each block group has an
|
# associated block group descriptor; these are present directly after the
|
# superblock. Each block group descriptor contains the location of the
|
# inode table, and the inode and block bitmaps (note these bitmaps are only
|
# a block long, which gets us the 8 * Block Size formula covered previously).
|
#
|
# 3) Blocks
|
# The ext4 filesystem is divided in blocks, of size s_log_block_size ^ 1024.
|
# Blocks can be allocated using individual block groups's bitmaps. Note
|
# that block 0 is invalid and its presence on extents/block tables means
|
# it's part of a file hole, and that particular location must be read as
|
# a block full of zeros.
|
#
|
# 4) Inodes
|
# The ext4 filesystem divides files/directories into inodes (originally
|
# index nodes). Each file/socket/symlink/directory/etc (here on out referred
|
# to as a file, since there is no distinction under the ext4 filesystem) is
|
# stored as a /nameless/ inode, that is stored in some block group's inode
|
# table. Each inode has s_inode_size size (or GOOD_OLD_INODE_SIZE if it's
|
# an old filesystem), and holds various metadata about the file. Since the
|
# largest inode structure right now is ~160 bytes, the rest of the inode
|
# contains inline extended attributes. Inodes' data is stored using either
|
# data blocks (under ext2/3) or extents (under ext4).
|
#
|
# 5) Extents
|
# Ext4 inodes store data in extents. These let N contiguous logical blocks
|
# that are represented by N contiguous physical blocks be represented by a
|
# single extent structure, which minimizes filesystem metadata bloat and
|
# speeds up block mapping (particularly due to the fact that high-quality
|
# ext4 implementations like linux's try /really/ hard to make the file
|
# contiguous, so it's common to have files with almost 0 fragmentation).
|
# Inodes that use extents store them in a tree, and the top of the tree
|
# is stored on i_data. The tree's leaves always start with an
|
# EXT4_EXTENT_HEADER and contain EXT4_EXTENT_INDEX on eh_depth != 0 and
|
# EXT4_EXTENT on eh_depth = 0; these entries are always sorted by logical
|
# block.
|
#
|
# 6) Directories
|
# Ext4 directories are files that store name -> inode mappings for the
|
# logical directory; this is where files get their names, which means ext4
|
# inodes do not themselves have names, since they can be linked (present)
|
# multiple times with different names. Directories can store entries in two
|
# different ways:
|
# 1) Classical linear directories: They store entries as a mostly-linked
|
# mostly-list of EXT4_DIR_ENTRY.
|
# 2) Hash tree directories: These are used for larger directories, with
|
# hundreds of entries, and are designed in a backwards compatible way.
|
# These are not yet implemented in the Ext4Dxe driver.
|
#
|
# 7) Journal
|
# Ext3/4 filesystems have a journal to help protect the filesystem against
|
# system crashes. This is not yet implemented in Ext4Dxe but is described
|
# in detail in the Linux kernel's documentation.
|
##
|
|
|
[Defines]
|
INF_VERSION = 0x00010005
|
BASE_NAME = Ext4Dxe
|
MODULE_UNI_FILE = Ext4Dxe.uni
|
FILE_GUID = 75F2B676-D73B-45CB-B7C1-303C7F4E6FD6
|
MODULE_TYPE = UEFI_DRIVER
|
VERSION_STRING = 1.0
|
|
ENTRY_POINT = Ext4EntryPoint
|
UNLOAD_IMAGE = Ext4Unload
|
|
#
|
# The following information is for reference only and not required by the build tools.
|
#
|
# VALID_ARCHITECTURES = IA32 X64 EBC
|
#
|
|
[Sources]
|
Ext4Dxe.c
|
Partition.c
|
DiskUtil.c
|
Superblock.c
|
BlockGroup.c
|
Inode.c
|
Directory.c
|
Extents.c
|
File.c
|
Collation.c
|
Crc32c.c
|
Crc16.c
|
Ext4Disk.h
|
Ext4Dxe.h
|
|
[Packages]
|
MdePkg/MdePkg.dec
|
RedfishPkg/RedfishPkg.dec
|
|
[LibraryClasses]
|
UefiRuntimeServicesTableLib
|
UefiBootServicesTableLib
|
MemoryAllocationLib
|
BaseMemoryLib
|
BaseLib
|
UefiLib
|
UefiDriverEntryPoint
|
DebugLib
|
PcdLib
|
OrderedCollectionLib
|
BaseUcs2Utf8Lib
|
|
[Guids]
|
gEfiFileInfoGuid ## SOMETIMES_CONSUMES ## UNDEFINED
|
gEfiFileSystemInfoGuid ## SOMETIMES_CONSUMES ## UNDEFINED
|
gEfiFileSystemVolumeLabelInfoIdGuid ## SOMETIMES_CONSUMES ## UNDEFINED
|
|
[Protocols]
|
gEfiDiskIoProtocolGuid ## TO_START
|
gEfiDiskIo2ProtocolGuid ## TO_START
|
gEfiBlockIoProtocolGuid ## TO_START
|
gEfiSimpleFileSystemProtocolGuid ## BY_START
|
gEfiUnicodeCollationProtocolGuid ## TO_START
|
gEfiUnicodeCollation2ProtocolGuid ## TO_START
|
|
[Pcd]
|
gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultLang ## SOMETIMES_CONSUMES
|
gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultPlatformLang ## SOMETIMES_CONSUMES
|
