Teach ufs_module.c about bsd partitions, at least a little.

[imp]

Summary

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.

[imp]

Doh! blocks, not bytes, for this arg.

[emaste]

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 ↗

(On Diff #43074)

char *buffer[]?
also stack variable ordering

89 ↗

(On Diff #43074)

s/normal/common/ or s/normal//?

99–100 ↗

(On Diff #43074)

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 ↗

(On Diff #43074)

return style

[emaste]

stand/efi/boot1/ufs_module.c

105 ↗

(On Diff #43074)

perhaps include a || dl->d_partitions[0].p_offset == 0) case?

[imp]

Address Ed's comments

[imp]

Better comment about GPT case

[imp]

Updated to address comments

stand/efi/boot1/ufs_module.c

82 ↗

(On Diff #43074)

Doh! Yea, right. bad. It works because sizeof(char *) > sizeof(char)

99–100 ↗

(On Diff #43074)

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 ↗

(On Diff #43074)

Sure, it's an optimization, but likely a good one.

[emaste]

stand/efi/boot1/ufs_module.c

99–100 ↗

(On Diff #43074)

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.

[emaste]

Overall looks good to me. Potential worries would be stack usage and 4k block size issues.

[emaste]

stand/efi/boot1/ufs_module.c

82 ↗

(On Diff #43074)

these should still be reordered largest to smallest

[imp]

Multiple disks require that we don't use globals.

[emaste]

Successfully tested the updated version in QEMU in both EFI and CSM modes.