123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149 |
- ## @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
- Symlink.c
- Collation.c
- Ext4Disk.h
- Ext4Dxe.h
- BlockMap.c
- [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
|