In addition to seeing if we can find a UFS partition at offset 0 on
the disk, check to see if there's a BSD disklabel at offset 512
(bytes) and if so, try to use the 'a' partition from that to boot
probe as well.
Details
Details
Diff Detail
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 16884 Build 16761: arc lint + arc unit
Event Timeline
Comment Actions
A MBR+EFI image with this change booted for me in QEMU in both UEFI and BIOS modes.
| stand/efi/boot1/ufs_module.c | ||
|---|---|---|
| 82 | char *buffer[]? | |
| 89 | s/normal/common/ or s/normal//? | |
| 99–100 | Maybe a static_assert that we're building on a little-endian system? Although hopefully we svn rm efi/boot1 before we look at EFI on say BE MIPS. | |
| 106 | return style | |
| stand/efi/boot1/ufs_module.c | ||
|---|---|---|
| 105 | perhaps include a || dl->d_partitions[0].p_offset == 0) case? | |
Comment Actions
Updated to address comments
| stand/efi/boot1/ufs_module.c | ||
|---|---|---|
| 82 | Doh! Yea, right. bad. It works because sizeof(char *) > sizeof(char) | |
| 99–100 | I don't see the point. UEFI is defined in the standard to be little endian. It's quite pervasive through everything, top to bottom. We will never have a BE UEFI thing it's so pervasive.... | |
| 105 | Sure, it's an optimization, but likely a good one. | |
| stand/efi/boot1/ufs_module.c | ||
|---|---|---|
| 99–100 | Fair enough - this one spot is not the right place to make sure we don't try going down the UEFI path on a BE host. | |
Comment Actions
Overall looks good to me. Potential worries would be stack usage and 4k block size issues.
| stand/efi/boot1/ufs_module.c | ||
|---|---|---|
| 82 | these should still be reordered largest to smallest | |