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

[Davidlohr Bueso <dave@gnu.org>]

On Mon, 2012-09-24 at 10:20 +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.
> 
>  struct fdisk_parttype {
>     const char *type;           /* UUID, 0xNN, ... */
>     const char *description;    /* help string */
>  };
> 
>  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).
> 
> > >  It also seems that you're introduce a new hex codes for GPT partition
> > >  types. It means that you want to use int16_t to address types defined
> > >  by UUIDs.  Is it good idea? Would be better to address the types by
> > >  numbers <1-N> as printed in the menu or directly by UUIDs?
> > 
> > True, 1 through N is probably better - I'll look into it. In any case I don't
> > see why we're showing the user (ie: 'l' menu option) hex values, we could easily
> > just show decimal and any number for any partition type. Perhaps I'm missing something
> > about standards, but I clearly remember certain values types, like 'Linux swap' to always
> > be specified by value 82 (hex), which we can see defined in fdisk.h.
> > 
> > So would it be ok to be able to change these values if needed?
> 
>  We have to support the real values for backward compatibility and for
>  extendability -- it should be possible to specify arbitrary
>  UUID. I think the best is to support the both ways
> 
>     - index value <1-N>
>     - real values (hex for DOS, strings for Mac, UUID for GPT, ...)
> 

Ok, I'm a little lost here. What I'm referring to is what we present to
the user for choosing a partition type. Currently we only use hex
values. I don't think we should bother the user with UUIDs here. Maybe
I'm just misreading this.

Thanks.