From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Thu, 06 Sep 2012 12:55:45 -0600 Subject: [U-Boot] [PATCH 4/6] gpt: Support for GPT (GUID Partition Table) restoration In-Reply-To: <20120906131907.21b859bd@amdc308.digital.local> References: <1345795995-24656-1-git-send-email-l.majewski@samsung.com> <1345795995-24656-5-git-send-email-l.majewski@samsung.com> <5047ACD2.1030909@wwwdotorg.org> <20120906131907.21b859bd@amdc308.digital.local> Message-ID: <5048F1B1.50503@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 09/06/2012 05:19 AM, Lukasz Majewski wrote: > Hi Stephen, > >> On 08/24/2012 02:13 AM, Lukasz Majewski wrote: >>> The restoration of GPT table (both primary and secondary) is now >>> possible. Simple GUID generation is supported. >> >>> diff --git a/include/part.h b/include/part.h >> >>> +int set_gpt_table(block_dev_desc_t *dev_desc, >>> + int parts, unsigned int *blocks, char *name[]); >> >> That interface seems very limiting; what if you want to select >> specific type UUIDs, set the partition attributes, leave gaps between >> the partitions, have the physical order of partitions (their block >> numbers) be different to the partition table ordering, etc. >> >> I wonder if it wouldn't be better to take an array of structures here, >> and have each entry define all the properties of the partition. That >> would allow fields to be added to the structure to describe more >> information as we add more functionality. > > I agree. > > I'd propose following approach: > > - set_gpt_table will receive a table with pointers to partition entries > (up to 128 entries in this table). In this way one can easily define > partition properties (which can be different for different > commands/boards). > > - I think, that Legacy MBR, and Primary/Secondary GPT shall be > generated in the set_gpt_table function. However I expect a problem > with one Primary/Secondary GPT field > - the Disk GUID. We can read it from environment, generate it or > hardcode it at ./include/boards/{target}.h > > > What is your opinion? Perhaps rather than /just/ taking a pointer to a table of partitions, take a pointer to a struct, which can hold both global properties and a pointer to the list of partitions?