On 4/25/19 1:36 PM, Eugeniu Rosca wrote:
Hi Roman,
...
On Thu, Apr 25, 2019 at 02:18:22PM +0300, roman.stratiienko@globallogic.com wrote:
From: Roman Stratiienko roman.stratiienko@globallogic.com
This allows retrieving uuid of the partition using it's name.
IMHO not seeing any real-life motivation (backed up by use-cases and, ideally, some commands/console output) in the patch description is the right recipe for getting no feedback from community. Fortunately, I am willing to put some time to fill this gap.
The story which I see behind the patch is that you are unhappy about not being able to pass the partition name in order to get the partition uuid. Currently, 'part' does require the partition index as input:
=> part uuid mmc 1:1 d117f98e-6f2c-d04b-a5b2-331a19f91cb2 => part uuid mmc 1:misc ** Bad partition specification mmc 1:misc **
It looks to me that pretty much the same driving force guided:
("cmd: part: Allow passing partition name to start and size")
("[U-Boot,v3,1/7] cmd: part: Add 'number' sub-command")
So, the motivation is clear to me (and I share it!).
The problem which I see with this patch is that it changes the usage pattern of the 'part uuid' sub-command, which breaks current (mainline and potential out-of-tree) users of 'part uuid'. Below occurrences in u-boot/master will require an update if this patch is merged as-is:
Yes, I don't think you want to change the cmdline format for this command, or all existing use-cases will break. That's not just the scripts you mentioned, but also people's own scripts stored on their own boot media or U-Boot environments, or just their memory of how to run the commands.
Right now IIRC the following works:
part uuid mmc 1:1
Perhaps we can make the following work, where the partitionk ID parameter isn't a simple integer, or where that ID doesn't exist:
part uuid mmc 1:"partname"
That should be backwards-compatible, and a sane enough syntax.
BTW, it looks like the patch also re-orders a bunch of code while editing it. I guess this is to keep the code that handles all the sub-commands in alphabetical order, which is fine. However, such cleanup should be a separate patch, so that the patch which introduces new/changed behaviour /only/ does that, so it's clear what's going on.