rust-kernel
Rustbelt: a hobby x86_64 kernel written in Rust
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 | //! Build script, two jobs:
//!
//! 1. Compile the user programs in user/ into ELF executables in OUT_DIR.
//! They're compiled with plain `rustc` for the built-in
//! `x86_64-unknown-none` target (prebuilt `core`, so no build-std
//! needed), as static executables (`relocation-model=static`) linked at a
//! high user address -- which needs the `large` code model (the default
//! ones assume code in the low/high 2 GiB).
//!
//! 2. Build the second QEMU disk, `target/disk.img` (64 MiB):
//! * a GPT partition table (made with `sfdisk`) with one partition
//! starting at sector 2048 (1 MiB, the usual alignment),
//! * in it a FAT32 file system (`mkfs.vfat`), filled with `mtools`
//! (`mmd`/`mcopy` write into an image file directly -- no root, no
//! loop-mounting needed): everything in disk/ plus the user programs
//! in /bin.
//! The kernel finds the disk on the PCI bus, reads the GPT, mounts the
//! FAT32 partition at /mnt/disk0 and loads programs from /mnt/disk0/bin.
//! QEMU opens it with `snapshot=on`, so the kernel's writes never change
//! this file (every boot and every test starts from the same disk).
//!
//! 3. Build the third QEMU disk, `target/ext2.img` (32 MiB): a whole-disk
//! ext2 file system (no partition table) made by `mke2fs -d`, which
//! copies a directory tree into the new file system. The tree is disk2/
//! plus generated files: big.txt (big enough for double-indirect blocks),
//! sparse.bin (66 MiB of mostly holes, reaching the triple-indirect
//! blocks), and two symlinks (one short = "fast", one long = "slow").
//! Mounted at /mnt/disk1 (drive C: in the shell).
//! Two more small images are for `cargo test` only (see Cargo.toml
//! test-args): ext2-4k.img (4 KiB blocks) and ext2-rev0.img (the original
//! 1993 revision 0 format: fixed 128-byte inodes, no file types in
//! directory entries).
//!
//! Needs dosfstools (mkfs.vfat), mtools (mmd, mcopy), fdisk (sfdisk) and
//! e2fsprogs (mke2fs):
//! sudo apt install dosfstools mtools fdisk e2fsprogs
use ;
/// Everything in /bin on the disk: the shell, its tools, and the test and
/// demo programs of the earlier stages.
const PROGRAMS: & = &;
const DISK_SECTORS: u64 = 64 * 1024 * 1024 / 512;
const PART_START: u64 = 2048;
/// Leave 1 MiB at the end too (the backup GPT lives in the last 33 sectors).
const PART_SECTORS: u64 = DISK_SECTORS - 2 * PART_START;
/// Find a tool in PATH or the sbin directories (often not in a user's PATH).
/// The lines of big.txt: line i is `big.txt line {i:05}` (19 bytes with the
/// newline), so tests can check any offset. 16000 lines = 304000 bytes:
/// with 1 KiB blocks that's past the 12 direct + 256 single-indirect blocks.
pub const BIG_LINES: usize = 16000;
/// sparse.bin: 66 MiB, all holes except these 1 KiB chunks of text. With
/// 1 KiB blocks, 40 MiB is in the double-indirect range and 65 MiB in the
/// triple-indirect range (which starts at 12 + 256 + 256*256 KiB ~ 64.3 MiB).
pub const SPARSE_SIZE: u64 = 66 * 1024 * 1024;
pub const SPARSE_MARKS: & = &;
/// Copy a directory tree (files and directories only).
|