[U-Boot] [PATCH 2/2] cmd:gpt: randomly generate each partition uuid if undefined

[Przemyslaw Marczak]

On 03/03/2014 05:46 PM, Tom Rini wrote:
> On Mon, Mar 03, 2014 at 04:31:35PM +0100, Przemyslaw Marczak wrote:
>> Hello Tom,
>>
>> On 03/03/2014 03:13 PM, Tom Rini wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 03/03/2014 08:45 AM, Przemyslaw Marczak wrote:
>>>
>>> [snip]
>>>> Actually automatically generated uuids was the main purpose of this
>>>> patches. Setting each env variable in this place was the most easy way
>>>> to make this without a lot of duplicated code.
>>>>
>>>> Why do you treat it like a side-effect?
>>>> If user wants have own generated uuids - then he can manually set env
>>>> variables like "uuid_gpt_disk".
>>>> This actually is not changed - when uuid env is set then it will be used
>>>> like in current version of code.
>>>> When user can't generate uuids or just wants to have it automatically
>>>> generated then my code do this job.
>>>
>>> Having been using this code again myself recently, at the high level,
>>> this is useful.  Having to copy/paste in N UUIDs gets silly.  But I also
>>> wonder..
>>>
>>> [snip]
>>>> The one and only reason for put saveenv() here was that if uuids are
>>>> randomly generated or even just are in environment then I can be sure
>>>> that next gpt write (e.g. in case of overwrite sector 0 by mistake) is
>>>> using the same uuids values.
>>>
>>> Is this really an important use case to cover?
>>
>> It can be important if somebody uses UUIDS to boot kernel. In kernel
>> documentation you can find a notice about kernel function
>> name_to_dev_t() - so by command line you can pass uuid for root
>> partition. And the same is for arg "suspend" in kernel cmd line.
>
> Right.  But that seems to be putting things in the wrong order.  If you
> need to restore UUIDs to your partition table, you pass in the optional
> and already known UUID.  If you're starting from scratch, by the time
> the installer is run U-Boot is long gone.  And tying things back to the
> commodity distro stuff, we would be fetching 'root=UUID=...' from some
> file generated and controlled on the Linux side of things anyhow.  To be
> clear, on the OS side of the equation there's much better ways to find
> out that partition1 has a UUID of ... than poking the U-Boot
> environment.
>

Ok, I understand this.

>>> The way I see things, would it be possible (and not a pain) to make the
>>> UUID part of the partition string passed to 'gpt write' optional.  If
>>> not passed, generate the UUIDs needed.  What was used would be seen in
>>> 'part list' and so forth.
>>
>> Ok, so I remove saveenv() from my changes and then we will have two cases:
>>
>> # gpt write mmc 0 $partitions
>> case 1: envorinment uuids are not set; then:
>>    proper uuids variables are set automatically (and printed)
>
> I'd go so far as to say we don't need to print the uuids, they're
> available via 'part list ...'.  A notice that we're generating UUIDs is
> probably not too spammy.
>

Ok, I will remove this notice.

>> case 2: environment uuids are set in env (e.g. some user has put his
>> own env); then
>>    users uuids will be used and new uuids are not generated automatically
>>
>> So this will not change current "gpt" usability - just add new
>> feature, moreover user will be informed about each uuid generation.
>> In case when someone use gpt write by mistake and overwrite uuids by
>> randomly generated then he can easily back to his own uuids by
>> setting each in environment and run gpt write again.
>
> Right.  We're making the use case of "fresh device, create new table"
> easier and we're still allowing "existing device, re-establish old
> UUIDs".
>
That's the point.

>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

Thanks,
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com