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? Thomas _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
