On 12.04.2012 16:53, tripun goel wrote: > On Thu, Apr 12, 2012 at 8:17 PM, Vladimir 'φ-coder/phcoder' Serbinenko > <phco...@gmail.com> wrote: >> On 12.04.2012 16:43, tripun goel wrote: >>> Please see if this helps ? >>> http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel64§ion=8 >> It doesn't. You need on-disk format. >> > 72/* > 73 * A disklabel64 starts at slice relative offset 0, NOT SECTOR 1. In > 74 * otherwords, d_magic is at byte offset 512 within the slice, regardless > 75 * of the sector size. > 76 * > 77 * The d_reserved0 area is not included in the crc and any kernel writeback > 78 * of the label will not change the d_reserved area on-disk. It is purely > 79 * a shim to allow us to avoid sector calculations when reading or > 80 * writing the label. Since byte offsets are used in our 64 bit disklabel, > 81 * the entire disklabel and the I/O required to access it becomes > 82 * sector-agnostic. > 83 */ > 84struct disklabel64 { > 85 char d_reserved0[512]; /* reserved or unused */ > 86 u_int32_t d_magic; /* the magic number */ > 87 u_int32_t d_crc; /* crc32() d_magic thru last part */ > 88 u_int32_t d_align; /* partition alignment requirement */ > 89 u_int32_t d_npartitions; /* number of partitions */ > 90 struct uuid d_stor_uuid; /* unique uuid for label */ > 91 > 92 u_int64_t d_total_size; /* total size incl everything (bytes) */ > 93 u_int64_t d_bbase; /* boot area base offset (bytes) */ > 94 /* boot area is pbase - bbase */ > 95 u_int64_t d_pbase; /* first allocatable offset (bytes) */ > 96 u_int64_t d_pstop; /* last allocatable offset+1 (bytes) */ > 97 u_int64_t d_abase; /* location of backup copy if not 0 */ > 98 > 99 u_char d_packname[64]; > 100 u_char d_reserved[64]; > 101 > 102 /* > 103 * Note: offsets are relative to the base of the slice, NOT to > 104 * d_pbase. Unlike 32 bit disklabels the on-disk format for > 105 * a 64 bit disklabel remains slice-relative. > 106 * > 107 * An uninitialized partition has a p_boffset and p_bsize of 0. > 108 * > 109 * If p_fstype is not supported for a live partition it is set > 110 * to FS_OTHER. This is typically the case when the filesystem > 111 * is identified by its uuid. > 112 */ > 113 struct partition64 { /* the partition table */ > 114 u_int64_t p_boffset; /* slice relative offset, in bytes */ > 115 u_int64_t p_bsize; /* size of partition, in bytes */ > 116 u_int8_t p_fstype; > 117 u_int8_t p_unused01; /* reserved, must be 0 */ > 118 u_int8_t p_unused02; /* reserved, must be 0 */ > 119 u_int8_t p_unused03; /* reserved, must be 0 */ > 120 u_int32_t p_unused04; /* reserved, must be 0 */ > 121 u_int32_t p_unused05; /* reserved, must be 0 */ > 122 u_int32_t p_unused06; /* reserved, must be 0 */ > 123 struct uuid p_type_uuid;/* mount type as UUID */ > 124 struct uuid p_stor_uuid;/* unique uuid for storage */ > 125 } d_partitions[MAXPARTITIONS64];/* actually may be more */ > 126}; This is very different from standard BSD and is most similar to Apple partition map actually. I recommend using this code as base and naming it "dragon" since it seems to be unique to DragonFly whereas other BSD opt for GPT. > >> -- >> Regards >> Vladimir 'φ-coder/phcoder' Serbinenko >> >> >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel >> > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
