Re: [PATCH 1/3] fdisk: add guid

[Davidlohr Bueso <dave@gnu.org>]

On Mon, 2012-09-24 at 10:43 +0200, Karel Zak wrote:
> On Mon, Sep 24, 2012 at 10:20:58AM +0200, Karel Zak wrote:
> > On Fri, Sep 21, 2012 at 11:04:51AM -0400, Davidlohr Bueso wrote:
> > > On Fri, Sep 21, 2012 at 04:38:16PM +0200, Karel Zak wrote:
> > > > On Fri, Sep 21, 2012 at 09:05:43AM -0400, Davidlohr Bueso wrote:
> > > > > I honestly don't see much difference between doing it before or
> > > > > after GPT, since all the other labels need to be adapted anyway. 
> > > > 
> > > >  I see a difference. Why we need struct fdisk_guid in struct where we
> > > >  define DOS partition types? Why there is {0} everywhere?
> > > >  Do you want to remove all these changes later?
> > > 
> > > My idea of having a unique systypes structure for all labels is for simplicity.
> > > I agree, using {0} isn't the best approach, so it would obviously go out, in favor
> > > of the same one the other labels would use. So if DOS doesn't need the GUID it just
> > > won't use it (and just call ->type or ->name), but it would still be there for those 
> > > that do require it, like GPT.
> > 
> >  Maybe we can use strings.
> 
> I mean strings for UUIDs, for DOS we can keep integers there.
> 
> 
> >  struct fdisk_parttype {
> 
>       unsigned int code;
> 
> >     const char *type;           /* UUID, 0xNN, ... */
> >     const char *description;    /* help string */
+      int visibility;
> >  };

One more thing. We also need a way of hiding parttypes from labels that
don't use them. I was thinking on using a similar approach we have with
the expert and common menus, just bitmasking the label types.

{0x8200, "0657FD6D-A4AB-43C4-84E5-0933C84B4F4F", N_("Linux Swap"), ANY_LABEL }

> >
> >  The fdisk dialogs and menus are always based on strings and the final
> >  conversion to label specific type (int or GUID) may be done in label
> >  specific functions (like add_partition or so).
> 
> I'll try to prepare a patch... it's the best way how to explain any
> idea :-)
> 
>     Karel
>