Hi Stephen, > On 09/13/2012 02:10 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, > > + gpt_header *gpt_h, gpt_entry *gpt_e); > > The API here isn't very generic; it requires the caller to have > formatted the GPT entirely by itself, which means having complete > knowledge of how to lay out a GPT header and partition table entry. > Right now, all that knowledge is contained inside the implementation > of the "gpt" command - what if some other unrelated code wanted to > write a GPT; it'd have to duplicate everything.
I must admit, that you are correct here. > > I was thinking of a much more generic interface, where each partition > is described using abstract structs, and the creation of the actual > on-disk layout is handling inside the set_gpt_table() function. That > would presumably allow the same abstract structs to be passed to e.g. > set_mbr_partition_table() and a generic "ptable create" command to be > created. If I understood you correctly, you propose to devise an abstraction layer to store information about each partition - e.g. struct partition { char *name, size_t size, size_t start, ... } then struct disk { struct partition p1, struct partition p2, ... } And then pass this struct disk to set_gpt_table() function. This would "clean" the partition related code and be a good starting point for further abstracting (if needed). -- Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot