On Thu, Aug 20, 2020 at 09:14:44AM -0700, James Bottomley wrote: > On Wed, 2020-08-19 at 20:21 -0300, Jason Gunthorpe wrote: > > On Wed, Aug 19, 2020 at 01:09:16PM -0700, James Bottomley wrote: > > > On Wed, 2020-08-19 at 14:17 -0300, Jason Gunthorpe wrote: > > > > On Wed, Aug 19, 2020 at 12:57:42PM -0400, Mimi Zohar wrote: > > > > > On Wed, 2020-08-19 at 13:18 -0300, Jason Gunthorpe wrote: > > > > > > Yes - it was dropped because TPM 2 was a *complete ABI break* > > > > > > for everything. The kernel was reset to a uABI that matches > > > > > > current uABI standards starting TPM 2. > > > > > > > > > > > > The whole userspace needed to be redone anyhow, and certainly > > > > > > nobody objected at the time. > > > > > > > > > > > > At least my expecation was that a sensible userspace for TPM > > > > > > (for administrator user) would be built, like we see in other > > > > > > subsystems eg 'ip' for netdev. > > > > > > > > > > "Because TPM 2 was a complete ABI break for everything" could > > > > > be reason for upstreaming a minimal subset of functionality > > > > > initially, which could be expanded over time. I don't recall a > > > > > discussion about limting features in the future. > > > > > > > > All new uAPI additions need to pass the usual uAPI hurdles. > > > > > > > > As James outlined, justify why the kernel must present a > > > > duplicated uAPI between sysfs and /dev/tpm. > > > > > > > > There have been good reasons in the past, eg SCSI inquiry. > > > > > > First, can we please agree /dev/tpm does not substitute as a > > > "duplicate API". > > > > Er? Huh? How so? > > Because like the SCSI command interface it's a binary marshalled > protocol we want to abstract for users. We can still argue whether the > kernel or a toolkit should do the abstraction but it's not one we want > to dump on users and say "this is it, what do you mean you don't like > it?" No we don't. On the contrary, we expose the protocol through /dev/tpm0. /Jarkko
