From mboxrd@z Thu Jan 1 00:00:00 1970 From: Przemyslaw Marczak Date: Mon, 03 Mar 2014 18:58:18 +0100 Subject: [U-Boot] [PATCH 2/2] cmd:gpt: randomly generate each partition uuid if undefined In-Reply-To: <5314BD44.9040909@ti.com> References: <72629ef58556732156fadf26a2a48be85704f224.1393600504.git.p.marczak@samsung.com> <722df36b26b2bb5657a113a7aabe72d95e475ca4.1393600504.git.p.marczak@samsung.com> <5310C151.4050009@wwwdotorg.org> <53148766.6080608@samsung.com> <53148DF6.5090401@ti.com> <5314A057.7070607@samsung.com> <20140303164621.GT16805@bill-the-cat> <5314BAAF.9010602@samsung.com> <5314BD44.9040909@ti.com> Message-ID: <5314C2BA.6010201@samsung.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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