On Sun, Dec 11, 2022 at 10:16:42PM -0500, James Bottomley wrote: > On Mon, 2022-12-12 at 00:52 +0000, Jarkko Sakkinen wrote: > > On Sun, Dec 11, 2022 at 03:01:57PM -0500, James Bottomley wrote: > > > On Sat, 2022-12-10 at 02:09 +0000, Jarkko Sakkinen wrote: > > > > On Fri, Dec 09, 2022 at 11:06:01AM -0500, James Bottomley wrote: > > > > > This separates out the old tpm_buf_... handling functions from > > > > > static > > > > > inlines in tpm.h and makes them their own tpm-buf.c file. This > > > > > is > > > > > a > > > > > precursor so we can add new functions for other TPM type > > > > > handling > > > > > > > > > > Signed-off-by: James Bottomley > > > > > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > > > > > > > > I don't comprehend that explanation at all. > > > > > > > > Please, add a bit more detail why this precursory change is > > > > required. > > > > > > It's the usual submitting-patches requirement of moving code first > > > before modifying it. Since it's the recommended way of doing > > > things in our process docs, I'm not sure how much more explanation > > > can be given. > > > > It doesn not contain any reasonable argument for not continue > > using inline functions. > > In principle nothing prevents them being inlines in tpm.h. There's > quite a lot of them, so it's growing unweildy and __tpm_buf_init can't > be hidden in that scenario but it could, in theory, be done. So: all I'm asking write this down. I'm cool with it, i.e. since complexity will grow heavily because of TPM2B structure handling etc. it is better to encapsulate he implementation, correct? BR, Jarkko
