Date: Mon, 15 Oct 2012 10:56:18 -0600
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Peter.Huewe@infineon.com, key@linux.vnet.ibm.com,
        tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable
 multiple times
Message-ID: <20121015165618.GA375@obsidianresearch.com>
References: <20120930233345.GJ30637@obsidianresearch.com>
 <20121010163324.GB5013@ennui.austin.ibm.com>
 <20121012205658.GM4124@obsidianresearch.com>
 <74A44E99E3274B4CB570415926B37D440ED140@MUCSE501.eu.infineon.com>
 <20121015163945.GA32563@obsidianresearch.com>
 <20121015174922.31fbadd9@pyramind.ukuu.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20121015174922.31fbadd9@pyramind.ukuu.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1364
Lines: 31

On Mon, Oct 15, 2012 at 05:49:22PM +0100, Alan Cox wrote:

> > > > Using open/close is an interesting idea, but it wouldn't work. open()
> > > > is coded to return EBUSY if another process has it open, rather than
> > > > block, and spinning on open would be unacceptable.
> > > 
> > > Hmm, maybe write a small pass through program which opens /dev/tpm
> > > once and accepts its data via a socket or pipe?
> > 
> > I believe the kernel should not be enforcing this kind of policy into
> > userspace. Plus, some of our embedded system are memory constrained
> > so an unnecessary process is not welcome..
> 
> Sane device drivers for devices where contention is meaningful block on
> an open that is busy, or return an error if the O_NONBLOCK option is
> specified. That's the normal case.

We have here a situation where there is no kernel or hardware
requirement for exclusivity, but the current driver enforces it, for
userspace only. Today the kernel and user space can access the TPM
device concurrently.

So, I would like to migrate the userspace interface to allow
non-exclusivity, but how do we do this?

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/