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.marc...@samsung.com
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
