Re: disklabel support

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3693 bytes --]

On 12.04.2012 16:53, tripun goel wrote:
> On Thu, Apr 12, 2012 at 8:17 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> <phcoder@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&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
>> 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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]