From mboxrd@z Thu Jan 1 00:00:00 1970 From: Przemyslaw Marczak Date: Mon, 03 Mar 2014 18:23:59 +0100 Subject: [U-Boot] [PATCH 2/2] cmd:gpt: randomly generate each partition uuid if undefined In-Reply-To: <20140303164621.GT16805@bill-the-cat> 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> Message-ID: <5314BAAF.9010602@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 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