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

[Przemyslaw Marczak <p.marczak@samsung.com>]

On 03/03/2014 06:35 PM, Tom Rini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/03/2014 12:23 PM, Przemyslaw Marczak wrote:
>> 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.
>
> Yay for agreement then, even if it took a few rounds to see we're on the
> same side :)  I look forward to v2.
>
> - --
> Tom
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJTFL1DAAoJENk4IS6UOR1WT0EP/12dTZmJGcgZYPgIaRohWAjS
> Dk3n0PdkPszGic/n5j6un6b8gSck27cTI3aM5YvqRioRBTzw6tvGVoIBOfrtEKdZ
> EV78iqMq1cozL3o3VdltQlLAzdLzSMwkkEqdD9K4vWpihdr19PPPuaPlV0ynw4/D
> 6+a1azEqTtznx96bGIH0XLK37ZtVre0/n1+9nd+mQ/swibHQM84GNPdR1L5m3hnJ
> W80XCnX4wRh238KxXRKr/fqG5w9cVXFcsPWESXzfA+pzi9Jy37dkhMX3CyAGuwS0
> QDLz1gg4h6CYGCRulN6rfNYHbLg8YYbJ/5xa4/dSntUW84uZJRMq93T9yKYX+qKM
> Iezp+EKzoL3Lagz3K2GmwopazEd+0goEHauoQ8QUGDdgMGapXui5NBUNyke78JK8
> U/WszX6JOWjagenWHDYiBvPhwIWdGw3FUJVijutKhK8KpKKihC9eDOsdoxz+Lyfu
> agcZ8rtJ8s6QBEf+xo/PRS+twJeHuTe/CptORm52cXxPMrwOKK17UxrjLJIuDSDl
> fqVsUaUHmxFmUNU/k5SGI60d/nZGmi7j8EzMMRIK8DJ18Sk0FaBOj/PKo2xBf3RO
> afbnEQXi831j42V2HSOEEY6rKRzES9d0roSUFIe5EvP/s/1/O1OanimtrXRISjF9
> rKXW1zAJZKQlBbYoDOSa
> =eGvG
> -----END PGP SIGNATURE-----
>

I hope to send V2 tomorrow :)
Regards
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com