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
