Thomas Huth <th...@redhat.com> writes: > On Wed, 17 Jun 2015 17:34:13 +0530 > Nikunj A Dadhania <nik...@linux.vnet.ibm.com> wrote: > >> Nikunj A Dadhania <nik...@linux.vnet.ibm.com> writes: >> >> > Thomas Huth <th...@redhat.com> writes: >> >>> +\ Check for GPT MSFT BASIC DATA GUID - vfat based >> >>> +EBD0A0A2 CONSTANT GPT-BASIC-DATA-PARTITION-1 >> >>> +B9E5 CONSTANT GPT-BASIC-DATA-PARTITION-2 >> >>> +4433 CONSTANT GPT-BASIC-DATA-PARTITION-3 >> >>> +87C0 CONSTANT GPT-BASIC-DATA-PARTITION-4 >> >>> +68B6B72699C7 CONSTANT GPT-BASIC-DATA-PARTITION-5 >> >>> + >> >>> +: gpt-basic-data-partition? ( -- true|false ) >> >>> + block gpt-part-entry>part-type-guid l@-le GPT-BASIC-DATA-PARTITION-1 >> >>> = IF >> >>> + block gpt-part-entry>part-type-guid 4 + w@-le >> >>> + GPT-BASIC-DATA-PARTITION-2 = IF >> >>> + block gpt-part-entry>part-type-guid 6 + w@-le >> >>> + GPT-BASIC-DATA-PARTITION-3 = IF >> >>> + block gpt-part-entry>part-type-guid 8 + w@ >> >> >> >> Don't you have to byte-swap (w@-le) here, too? Looks somehow strange >> >> that the other UID parts are read byte-swapped but this one is not? >> > >> > Interesting observation, I had used code from gpt-prep-partition? and >> > did not doubt the validity of it. But that is how I see it in the memory >> > though. >> > >> > 4 > 7e50d000 10 dump >> > 7e50d000: a2 a0 d0 eb e5 b9 33 44 87 c0 68 b6 b7 26 99 c7 >> > ......3D..h..&.. ok >> > 4 > >> >> And here the answer for that: >> >> https://en.wikipedia.org/wiki/GUID_Partition_Table#cite_note-26 >> >> The GUIDs in this table are written assuming a little-endian byte >> order. For example, the GUID for an EFI System partition is written >> as C12A7328-F81F-11D2-BA4B-00A0C93EC93B here, which corresponds to >> the 16 byte sequence 28h 73h 2Ah C1h 1Fh F8h D2h 11h BAh 4Bh 00h A0h >> C9h 3Eh C9h 3Bh – only the first three blocks are byte-swapped. >> >> "only the first three blocks are byte-swapped" > > Ok, this seems to be a GUID specialty (as opposed to UUIDs), also see: > > https://en.wikipedia.org/wiki/Globally_unique_identifier#Binary_encoding > > ... but that means that the last 8 bytes are always "big endian", so I > think you could simplify your code here and check the last 8 bytes at > once instead of checking 2 + 6 bytes separately, can't you?
Yes, I am making these changes, will be sending the series after testing. Regards Nikunj _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
