On Mon, 2017-01-23 at 16:04 -0700, Jason Gunthorpe wrote:
> On Mon, Jan 23, 2017 at 02:57:11PM -0800, James Bottomley wrote:
> > On Mon, 2017-01-23 at 15:49 -0700, Jason Gunthorpe wrote:
> > > On Mon, Jan 23, 2017 at 02:28:23PM -0800, James Bottomley wrote:
> > > > On Mon, 2017-01-23 at 09:47 -0700, Jason Gunthorpe wrote:
> > > > > On Mon, Jan 23, 2017 at 01:44:32AM +0200, Jarkko Sakkinen
> > > > > wrote:
> > > > > > From: James Bottomley <
> > > > > > [email protected]>
> > > > > > 
> > > > > > Signed-off-by: James Bottomley
> > > > > > <[email protected]>
> > > > > 
> > > > > I really think we should not use the ugly read/write 
> > > > > interface for any new things.
> > > > 
> > > > The R/W interface is needed for backward compat,
> > > 
> > > With what? This is a new cdev with different semantics.
> > 
> > If you set TPM_DEVICE=/dev/tpms0 the old software just works.  If 
> > we remove the R/W interface, nothing will work.  The point being 
> > the new cdev has the same interface semantics, it just has 
> > different global behavour.
> 
> So you are saying there is so much already deployed TPM2 software 
> that has this TPM_DEVICE env var convention that we need to support 
> it with compat?
> 
> I'm really surprised by that.. But OK.
> 
> Can you at least remove the 'user_read_timer' junk from the new cdev?

What's the problem with it?  Can we not just fix whatever the issue is?

I'd rather reuse all the R/W machinery as is.  If I start trying to
special case it so that we only use some parts on some control flows,
the chances are I'll introduce additional bugs as well.

James

Reply via email to