CloverBootloader/Ext4Pkg/Ext4Dxe/Ext4Dxe.inf

## @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