finished looking at openbsd src

This commit is contained in:
Om Raheja 2024-08-19 16:44:54 -04:00
parent af7345c6b2
commit 0e21d3d77a
1 changed files with 33 additions and 0 deletions

View File

@ -135,3 +135,36 @@ e2fs_sbcheck(struct ext2fs *fs, int ronly)
```
The mask must again be the same meaning instead of what we traditionally think of in "bitmask"; its the way bits are ordered in the filesystem. Then we have `letoh16(3)` for the byte orderings, which converts 16-bits little endian to a number they can use to check for the magic number. The good news is that we can also use these functions and we don't have to worry about how the underlying logic works that well.
```c
tmp = letoh32(fs->e2fs_log_bsize);
if (tmp > 2) {
/* skewed log(block size): 1024 -> 0 | 2048 -> 1 | 4096 -> 2 */
tmp += 10;
printf("ext2fs: wrong log2(block size) %d\n", tmp);
return (EIO); /* XXX needs translation */
}
```
This looks like a limitation enforced by 32-bit mode; you can't have a block larger than 4096 bytes. This depends on what 32-bit mode actually means; but for the most part, I think we are spot on. Below that, we just have revision numbers and inode checks to see if it fits, but on line 1109, we have:
```c
tmp = letoh32(fs->e2fs_features_incompat);
mask = tmp & ~(EXT2F_INCOMPAT_SUPP | EXT4F_RO_INCOMPAT_SUPP);
if (mask) {
printf("ext2fs: unsupported incompat features: ");
for (i = 0; i < nitems(incompat); i++)
if (mask & incompat[i].mask)
printf("%s ", incompat[i].name);
printf("\n");
return (EINVAL); /* XXX needs translation */
}
```
This code begs the question: What is an "unsupported incompat" feature? Isn't it redundant to say that a feature is both unsupported and incompatible? We saw this earlier in `ext2fs.h` as well. Well, incompatible features mean that they are incompatible with the `EXT4_REV0`, and that's what read only compatible implies too. I suppose this must have been reserved in the past, or they knew a second revision was coming.
This is also the source of the error message we get when we try to mount ext4 read only!
More readonly flags, and then it checks for other features in a similar manner. At least now we have a better understanding of what is to be done!
The rest of this file looks like just copying more stuff over. While it may be useful later on, I think it's more important to start diving into the Linux code, and specifically looking for anything related to checksum or 64-bit mode, as well as noting if the superblock changes!