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

[Tom Rini]

-----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-----