On Sun, 2018-12-02 at 10:23 -0500, Mimi Zohar wrote: > On Fri, 2018-11-30 at 15:35 -0800, Jarkko Sakkinen wrote: > > Hi > > > > Some things that came up at LSS. > > > > First, would it be time to drop 1.1b bits? What advantages this > > would bring? AFAIK Peter is a strong supporter of this. > > > > In the hall way discussions, I talked with Tomas Winkler that it > > would make sense to add CONFIG_TCG_TPM1 flag to completely leave > > out all TPM 1.x bits from the kernel. > > > > TPM 1.x stuff is not exactly legacy but especially on IoT does not > > make sense to carry that code with. > > New systems might be shipping with only TPM 2.0, but it still needs > to be supported for existing systems, probably for quite a while. > Having the option to build the kernel with TPM 1.2, TPM 2.0 or both, > is acceptable. The distros won't thank you for yet another kconfig option. , especially one which could cause regressions if they choose the wrong value. However, having a hidden one which could be activated by driver might work ... on the other hand almost all the current drivers support both 1.2 and 2.0 so they'd all need splitting. The other thing that should give us pause is this: jejb@jarvis:~/git/linux/drivers/char/tpm> size tpm.o text data bss dec hex filename 35247 1120 32 36399 8e2f tpm.o Currently the combined tpm subsystem (without drivers) is less than 36k of code, so is splitting it up valuable? I think you're going to find we have a reasonable abstraction of sharing, so taking out 1.x by config will likely save less than 10k of code ... is that worth the effort? James
