On Thu, 2019-08-22 at 11:32 +0100, Daniel P. Berrangé wrote:
> On Thu, Aug 22, 2019 at 01:43:05AM +0300, Maxim Levitsky wrote:
> > On Tue, 2019-08-20 at 20:01 +0200, Max Reitz wrote:
> > > On 14.08.19 22:22, Maxim Levitsky wrote:
> > > > With upcoming key management, the header will
> > > > need to be stored after the image is created.
> > > >
> > > > Extracting load header isn't strictly needed, but
> > > > do this anyway for the symmetry.
> > > >
> > > > Also I extracted a function that does basic sanity
> > > > checks on the just read header, and a function
> > > > which parses all the crypto format to make the
> > > > code a bit more readable, plus now the code
> > > > doesn't destruct the in-header cipher-mode string,
> > > > so that the header now can be stored many times,
> > > > which is needed for the key management.
> > > >
> > > > Also this allows to contain the endianess conversions
> > > > in these functions alone
> > > >
> > > > The header is no longer endian swapped in place,
> > > > to prevent (mostly theoretical races I think)
> > > > races where someone could see the header in the
> > > > process of beeing byteswapped.
> > >
> > > The formatting looks weird, it doesn’t look quite 72 characters wide...
> > > (what commit messages normally use)
> >
> > Could you elaborate on that? I thought that code should not
> > exceed 80 character limit.
>
> Code itself should be wrapped at 80 chars, but it is common for
> commit messages to use 72 chars wrapping.
>
>
> Regards,
> Daniel
All right, will do this.
Best regards,
Maxim Levitsky
