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

[Karel Zak <kzak@redhat.com>]

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, ...)

  Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com