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 */
> };
>
> 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
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
