On Sun, Jun 18, 2017 at 4:03 AM, Wolfgang Denk <w...@denx.de> wrote: > Dear Alison, > > In message <CAOuSAjdHerD7iWSwv5HQmx07nALRHschnH5=XToNEZDqA9JsvQ@mail. > gmail.com> you wrote: > > > > The idea behind the 'swap' mode is that a storage device can have two > sets > > of partitions, one set all named 'primary' and one set all named > 'backup'. > > The software updater in userspace can then simply rename the partitions > > with sgdisk in order to pick the new image. The swap mode changes the > > whole set of labels at once, so there's little chance of being > interrupted. > > It's still a sequential, non-atomic operation, and "little chance" > is exactly the places where Murphy likes to hit you. > > > One additional note: the last version I posted worked fine for the > sandbox, > > but wouldn't link for an ARM target with the Linaro toolchain, as the > > linker couldn't find atoi(). I guess the libc for the x86 compiler > > includes it. To test on ARM, I copied in simple_atoi() from > > lib/vsprintf.c, but assuredly that is an ugly solution. Does anyone > have > > a better idea to solve this problem? > > U-Boot should always be self-contained and not link regular library > code from the tool chain. > > Best regards, > > Wolfgang Denk >
I'm about to submit a new version of the patches that adopts Wolfgang's and Tom's suggestions about replacing atoi(). Regarding the atomicity of 'gpt swap, the point is that 'gpt swap' first modifies the names in an in-memory data structure, and then uses the existing 'gpt write' functionality to change the actual partition table stored on the device. Thus, interruption of the new command is low-risk, as interruption of the modification of the new data structure has no persistent effect, and the risk associated with 'gpt write' is the same as always. By the way, in the course of testing an earlier version of this patch series, I noticed that 'gpt write' and 'gpt verify' segv if presented with a non-null-terminated partitions string. It's the strlen function in lib that actually generates an error. I haven't yet quite figured out what the best solution to the problem is: should strlen() itself be modified, or is it enough to test in gpt.c? The right solution is not to present the commands with poorly formed strings, but it's easy to do so. Mit freundlichen Grüße, Alison _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
