On Tue, Sep 24, 2019 at 07:12:40AM -0400, James Bottomley wrote: > I thought about that. The main problem is that most of the > construct/append functions use the header, and these are the functions > most useful to the TPM2B operation. > > The other thing that argues against this is that the TPM2B case would > save nothing if we eliminated the header, because we allocate a page > for all the data regardless. It would be way more clean. There is absolutely nothing TPM2B specific. > > and also it makes sense to have a separate length field in the > > struct to keep the code sane given that sometimes the buffer does not > > store the length. > > I'm really not sure about that one. The header length has to be filled > in for the non-TPM2B case but right at the moment we have no finish > function for the buf where it could be, so we'd end up having to > maintain two lengths in every update operation on non-TPM2B buffers. > That seems inefficient and the only slight efficiency we get in the > TPM2B case is not having to do the big endian conversion from the > header which doesn't seem to be worth the added complexity. It would be way more clean and an insignificant concern when it comes to performance. I don't see any problem updating two lengths. /Jarkko
