[PATCH] fdisk: Add support for GPT partition type codes

[Tito]

On 11/28/2016 05:42 PM, Simon Rettberg wrote:
> 27.11.2016, 20:24 +0200, Denys Vlasenko <vda.linux at googlemail.com>:
>
>> However, I still don't understand how do you use them,
>> apart from seeing them on output.
>>
>
> That's pretty much it. Following the same line of argument, you could
> ask why we have this table in fdisk.c that maps the MBR type ids
> to their names. They also do nothing except for showing up in the
> output.
>
> Plus, in case bb fdisk will get write support for GPT one day, the
> table would be even more useful, since you usually just enter the type
> code in existing GPT editing tools, instead of the full GUID. The
> utility then just maps the short type code back to the long GUID when
> writing.
>
> Actually, the type codes of GPT are based on the type ids from MBR,
> so for example HPFS/NTFS is 07 for MBR and 0700 for GPT, Linux Swap
> is 82 for MBR, 8200 for GPT.
Hi,
one stupid question, could the 2 tables be merged or reused in some way
as they share related values (e.g. 82 and 8200)?

Ciao,
Tito

>> When you send a patch, add a bit of background why do you need this
>> change,
>> and if there were other solutions which at first looked better, but
>> then proved
>> non-workable, mention those too.
>>
>> For example, before I saw your email, I looked at fdisk_gpt.c and
>> decided to simply delete "Code" column on the output. I take it this
>> is not a good idea?
>> Why?
>
> Alright, so as mentioned above, those type codes are almost exclusively
> used when humans are dealing with GPT partitions in any way.
>
> Not supporting them in busybox would not mean the end of the world; we
> could still do everything by reading (and some day writing) type GUIDs
> directly, at the expense of having to look them up manually every time,
> unless you can memorize them.
>
> As for removing the column: I saw that the formatting of the output
> looks exactly like that of gdisk, so I assumed the original author
> of fdisk_gpt.c decided that it would be better to print a dummy
> value than not having the column at all.
> I can't speak for the rest of the world, but I don't care about that
> output format compatibility, so I would be fine with not having that
> column instead of printing a misleading dummy value; it might
> actually be the more reasonable choice, since it had me confused for
> a while before checking the source. A new column showing the GUID
> directly would be ok with me. I would change my scripts and add a
> lengthy comment, probably.
> But showing neither the short code nor the GUID does render the output
> somewhat useless, just as if MBR mode would not print the type id.
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>