From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SKcRl-00023v-Eq for mharc-grub-devel@gnu.org; Wed, 18 Apr 2012 17:29:53 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SKcRg-00021m-2O for grub-devel@gnu.org; Wed, 18 Apr 2012 17:29:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SKcRb-00025M-DZ for grub-devel@gnu.org; Wed, 18 Apr 2012 17:29:47 -0400 Received: from mail-we0-f169.google.com ([74.125.82.169]:62617) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SKcRb-000251-2Q for grub-devel@gnu.org; Wed, 18 Apr 2012 17:29:43 -0400 Received: by werj55 with SMTP id j55so6464199wer.0 for ; Wed, 18 Apr 2012 14:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=uYPg3fG9nNqWXZ7H0U6bEoZI4JGLD8MA0MCj8ixGvxI=; b=Mo9JmF0qFAtLtzIDviC1NkV3L270G7avcnERPi7y4L2QRrUCgSvbRtZx9IWbDulhtr ghYsMivAg6EbNQthMCNMO35g5XfNZxlaqM1JrljDt1/ic3hCnn21YUc8xATatW9A+SbJ McQN0/eeVTHLID8ZKq6/I7Z6Q/1YG2ZYX9bwoFoskYH4KOWqpwiBgj+TDpua3kEU/0E2 NXvNieWDtfdG3SYK6HXyNdNVMLo2eEfb7PY1lnEex9a9Pi6eScOjDr+9kIrABB86TTY+ ojFK+Z4sOfEJWlGxqrqK05Rc5R4v3qUpqlNzSoq/LbWZFTS82NwCFj6A2oji24nhwsYS cWzg== Received: by 10.180.102.3 with SMTP id fk3mr9775432wib.9.1334784580923; Wed, 18 Apr 2012 14:29:40 -0700 (PDT) Received: from debian.x201.phnet (79-233.197-178.cust.bluewin.ch. [178.197.233.79]) by mx.google.com with ESMTPS id k6sm37356214wiy.7.2012.04.18.14.29.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Apr 2012 14:29:39 -0700 (PDT) Message-ID: <4F8F3238.40400@gmail.com> Date: Wed, 18 Apr 2012 23:29:28 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: disklabel support References: <4F86DFB9.4010702@gmail.com> <4F86EAE8.9080006@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3A054A4373951595B226C864" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 74.125.82.169 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 21:29:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3A054A4373951595B226C864 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12.04.2012 16:53, tripun goel wrote: > On Thu, Apr 12, 2012 at 8:17 PM, Vladimir '=CF=86-coder/phcoder' Serbin= enko > wrote: >> On 12.04.2012 16:43, tripun goel wrote: >>> Please see if this helps ? >>> http://leaf.dragonflybsd.org/cgi/web-man?command=3Ddisklabel64§io= n=3D8 >> 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, regard= less > 75 * of the sector size. > 76 * > 77 * The d_reserved0 area is not included in the crc and any kernel wri= teback > 78 * of the label will not change the d_reserved area on-disk. It is p= urely > 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 disk= label, > 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 '=CF=86-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 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig3A054A4373951595B226C864 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk+PMjgACgkQNak7dOguQgkT5gD/ahYNtp2Cl3kehSOGiazrt5Iy r+icrP1Gl1KaIbPSdIUA/2fOSaUZyuU9H9bGtmRUba//Tpkgj2TNqEGvpaQKN3QP =JyRu -----END PGP SIGNATURE----- --------------enig3A054A4373951595B226C864--