From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarkko Sakkinen Subject: Re: [RFC PATCH 3/4] Implement driver for supporting multiple emulated TPMs Date: Tue, 26 Jan 2016 19:13:20 -0800 Message-ID: <20160127031320.GC23863@intel.com> References: <201601201439.u0KEdFao027907@d03av05.boulder.ibm.com> <20160121011701.GA20361@obsidianresearch.com> <201601210301.u0L31h5r012187@d03av03.boulder.ibm.com> <20160121032115.GA26266@obsidianresearch.com> <201601210356.u0L3uP1n029818@d03av05.boulder.ibm.com> <20160121174243.GD3064@obsidianresearch.com> <201601211902.u0LJ2LbL001130@d03av01.boulder.ibm.com> <20160121193049.GA31938@obsidianresearch.com> <201601212151.u0LLpC93021986@d03av03.boulder.ibm.com> <20160121221040.GA1630@obsidianresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20160121221040.GA1630-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Jason Gunthorpe Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: tpmdd-devel@lists.sourceforge.net On Thu, Jan 21, 2016 at 03:10:40PM -0700, Jason Gunthorpe wrote: > On Thu, Jan 21, 2016 at 04:51:06PM -0500, Stefan Berger wrote: > > > > You can't let this influence the kernel UAPI design. > > > The choice is between getting this working 'today' (even if just > > locally) or discussing this with golang designers, which in the ideal > > case would cause me waiting for the next version, dealing with that > > version dependency etc., plus the delay. So, clearly, an additional > > ioctl() and ~50 lines of code make this work 'now'. Doesn't this seem > > worth it? > > Sorry, for mainline stuff like this reserve thing is not clean enough > to be acceptable. > > Why can't you just open-code a modified forkAndExecInChild in docker? > > Seriously, the golang code you showed already has special stuff to do > user namespaces before the exec, it is totally unreasonable insist I'm starting to be along the same lines with the Jason now that I've actually tried to read through the discussion up to this email. I did say something opposite in last week but will take my words back since I had too weak understanding back then (you *never* should response to dicussions like this when you are overloaded with something else). I haven't yet locked whether the fd or major/minor passing is the right choice but at least I do agree that we cannot make decission based on some golang code in Docker. For the new mainline code we should pick the most robust API, nothing more or less... /Jarkko ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140