Re: disklabel support

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 12.04.2012 16:53, tripun goel wrote:
> On Thu, Apr 12, 2012 at 8:17 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> <address@hidden> wrote:
>> On 12.04.2012 16:43, tripun goel wrote:
>>> Please see if this helps ?
>>> http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel64&section=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
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

signature.asc
Description: OpenPGP digital signature