[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170111191809.GA28593@obsidianresearch.com>
Date: Wed, 11 Jan 2017 12:18:09 -0700
From: Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To: Stefan Berger <stefanb@...ux.vnet.ibm.com>
Cc: Andreas Fuchs <andreas.fuchs@....fraunhofer.de>,
Ken Goldman <kgoldman@...ibm.com>, greg@...ellic.com,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
tpmdd-devel@...ts.sourceforge.net
Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager
On Wed, Jan 11, 2017 at 01:27:30PM -0500, Stefan Berger wrote:
> On 01/11/2017 01:03 PM, Jason Gunthorpe wrote:
> >On Wed, Jan 11, 2017 at 11:00:43AM +0100, Andreas Fuchs wrote:
> >
> >>could we please get an ioctl, that switches the "mode" of the fd entirely.
> >>I'd like to see the write()/read() support still intact.
> >>All my current code uses main-loop based poll on the fd and I don't want
> >>to be force to start using threads...
> >We currently do not support poll in the kernel for /dev/tpmX.
> >
> >ie we do not supply a poll method for 'struct file_operations'.
> >
> >Even worse, the current implementation blocks returning from write()
> >until the TPM has completed its work, so it doesn't even make sense to
> >combine it with poll.
>
> Newer applications could issue an ioctl() after the open() to unblock the
> write().
The ioctl api I outlined could support poll by having userspace set
the rxbuf = NULL.
The kernel would then launch the tx async and provide poll support to
allow read() to return the result once the tpm has finished.
This can be added as a new capability down the road..
Jason
Powered by blists - more mailing lists