On Tue, Sep 05, 2017 at 03:08:25PM +0200, Claudius Heine wrote: > > > On 09/05/2017 10:27 AM, [ext] Andreas Reichel wrote: > > From: Reichel Andreas <[email protected]> > > > > diff --git a/docs/UPDATE.md b/docs/UPDATE.md > > index 169fb9d..db3debf 100644 > > --- a/docs/UPDATE.md > > +++ b/docs/UPDATE.md > > @@ -11,8 +11,7 @@ The structure of the environment data is as follows: > > struct _BG_ENVDATA { > > uint16_t kernelfile[ENV_STRING_LENGTH]; > > uint16_t kernelparams[ENV_STRING_LENGTH]; > > - uint8_t testing; > > - uint8_t boot_once; > > + uint16_t ustate; > > I would still prefer the ustate to be uint8_t. > Yes, this is 'intrinsic padding' versus 'explicit padding'. Given the fact we only have a one-digit number of states, 256 different numbers surely suffice. If we introduce uint8_t padding, followed by uint8_t ustate, then testing is always zero and setting boot_once value is ignored by older boot loader versions. The current way, testing gets the low byte of ustate and thus is set to 1 if an image is installed. This would be compatible to the old behavior. However, the old boot loader would then set the high byte to one which would result in 257. Thus, I agree, it is better to have a padding byte before ustate.
Andreas > Claudius > -- Andreas Reichel Dipl.-Phys. (Univ.) Software Consultant [email protected], +49-174-3180074 TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082 -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/20170906152543.GB914%40iiotirae. For more options, visit https://groups.google.com/d/optout.
