Re: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
On Mon, 15 Oct 2012 10:39:45 -0600 Jason Gunthorpe wrote: > On Mon, Oct 15, 2012 at 08:35:09AM +, peter.hu...@infineon.com wrote: > > > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > > > > > 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. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
On Mon, Oct 15, 2012 at 08:35:09AM +, peter.hu...@infineon.com wrote: > > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > > > 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.. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
-Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > 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? Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
-Original Message- From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] 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? Thanks, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
On Mon, Oct 15, 2012 at 08:35:09AM +, peter.hu...@infineon.com wrote: From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] 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.. Jason -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
On Mon, 15 Oct 2012 10:39:45 -0600 Jason Gunthorpe jguntho...@obsidianresearch.com wrote: On Mon, Oct 15, 2012 at 08:35:09AM +, peter.hu...@infineon.com wrote: From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] 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. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
On Mon, Oct 01, 2012 at 09:07:11AM +, peter.hu...@infineon.com wrote: > Hi Jason, > > one quick question: > - TPM_BUFSIZE = 4096, > [...] > + u8 data_bufferx[2048]; > > Why do you half the buffer size? I missed 7f366784f5c2b8fc065 when I rebased the patch, thanks! Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
Hi Jason, one quick question: - TPM_BUFSIZE = 4096, [...] + u8 data_bufferx[2048]; Why do you half the buffer size? Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
Hi Jason, one quick question: - TPM_BUFSIZE = 4096, [...] + u8 data_bufferx[2048]; Why do you half the buffer size? Thanks, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
On Mon, Oct 01, 2012 at 09:07:11AM +, peter.hu...@infineon.com wrote: Hi Jason, one quick question: - TPM_BUFSIZE = 4096, [...] + u8 data_bufferx[2048]; Why do you half the buffer size? I missed 7f366784f5c2b8fc065 when I rebased the patch, thanks! Jason -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
