On 11/28/2016 05:42 PM, Simon Rettberg wrote:
27.11.2016, 20:24 +0200, Denys Vlasenko <[email protected]>:
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
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
