Ethin wrote:
What is the appropriate procedure for converting these "mixed endian" GUIDs into actual numbers?
Here's how I print them on little-endian machine (in C):
Code:
typedef struct {
uint32_t Data1;
uint16_t Data2;
uint16_t Data3;
uint8_t Data4[8];
} __attribute__((packed)) guid_t;
printf("%08x-%04x-%04x-%02x%02x%02x%02x%02x%02x%02x",guid->Data1,guid->Data2,guid->Data3,
guid->Data4[0],guid->Data4[1],guid->Data4[2],guid->Data4[3],guid->Data4[4],guid->Data4[5],guid->Data4[6],guid->Data4[7]);
So the first three fields are little-endian, and the last is big-endian.
But if you don't have to convert between ASCII and binary representations, then comparing a 16 bytes long byte array should suffice. For checking ids in GPT, 128-bit integers are perfect.
Ethin wrote:
Rust allows me to manipulate and store 128-bit integers. Currently I just take the hole GUID, convert the words from the ATA device to little endian bytes, and then convert those into 128-bit integers
No need to do endianess conversions as long as you specify those integers the same way as they are stored on disk in the GPT (and printed by your kernel). If they don't match, just flip the constant in your source and it should work.
Ethin wrote:
2) What is the proper procedure for verifying CRC32s for GPT? I tried a simple CRC32 algorithm and it failed verification.
Haha, there are many CRC32 algorithms. Castangoli polynomial won't work, and you have to start with full binary 1s and XOR the result by full binary 1s. It's called ANSI X3.66 CRC-32. Here's an
implementation (in C, sorry) that I use to generate GPT in an image file, and it calculates correct values. I think it should be trivial to convert this function into Rust.
Ethin wrote:
3) What is the method for detecting what filesystem is on the partition?
You could use the "Partition type GUID" field, but I rather would recommend checking for magic bytes in the superblock on the partition, that's more bullet-proof. So read a few sectors from "Starting LBA" into memory, and in case of ext2 check if the word at offset 56 on the third sector is 0xEF53 (if I recall correctly, please consult the spec for the correct offset and magic value).
Cheers,
bzt