From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4C1521A1E08 for ; Fri, 2 Sep 2016 11:05:17 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id v143so43576627wmv.0 for ; Fri, 02 Sep 2016 11:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=SkJptaM7m6+b6r3cZkUUE0QGo+6fXzHbNlA8HYLegcA=; b=c//OlkHA/NmzWyM0PnblHTFUjmxONGdkE9dCo6twGEn3FitHB8gdrti4jNI/Q/1GQr 1Jxblw4hyQPlP74EIAVd3ckrZy2BBYQzRube6olQrxDKnMgGrwKEk+eLmQ76tidQtMq3 bgGbsaPUDIqcqE+NNtkHhaKPuD0i3Z8ES+caw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=SkJptaM7m6+b6r3cZkUUE0QGo+6fXzHbNlA8HYLegcA=; b=Rt9PSPPcOWsTGyNQtb+OAPod57i5/+cYU+HJFhREXLAV2KMeFEidGFEhmeMewqtXln yW0hMg2a40r0D+kAzUQrRjBE4Xk5DEziTQWN195Z/krOenPdIN2uxP5vSYbi2MSWdjoS DuOpsv00+BWzsFaXtnzAEiyhLIW+QY4JX1OLIsKhOiYyMyDfOSD4SEh97TBKWloeuYJy cFYL+Bc4kla3hZ5nkNOAcsksZsODOICoclpIK1+Ad8t86gWhyj0ErjRy5ioWhCIG/jnX pwBldB3oOX6Geejn7xhnKGTzzESTeuVBys80+FvwpewhxsLsHVfXx6LQLeHjfXhULKNf fV7w== X-Gm-Message-State: AE9vXwNmrIHQnUBE0P9sBlD3GFQFhe3YeF6FIQgzyHiGLCBIXkK5HC5wuS4PBLUsBX6/d+LB X-Received: by 10.194.161.197 with SMTP id xu5mr10162752wjb.88.1472839515867; Fri, 02 Sep 2016 11:05:15 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id d85sm1959843wmd.0.2016.09.02.11.05.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Sep 2016 11:05:14 -0700 (PDT) Date: Fri, 2 Sep 2016 19:05:13 +0100 From: Leif Lindholm To: Ard Biesheuvel Cc: edk2-devel-01 , Laszlo Ersek , Michael D Kinney , Liming Gao Message-ID: <20160902180513.GE4715@bivouac.eciton.net> References: <20160902142912.17297-1-leif.lindholm@linaro.org> <20160902142912.17297-2-leif.lindholm@linaro.org> <6C8DC7F6-2459-4CD6-A556-3B17A1FBBF5F@linaro.org> <20160902152351.GB4715@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [PATCH 1/3] MdePkg/Misc: Move ARM* BaseMemoryLibStm to MdePkg X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 18:05:17 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 02, 2016 at 05:07:48PM +0100, Ard Biesheuvel wrote: > > This isn't a proposed alternative to your patchset, this is an > > alternative to reverting all of the other BaseMemoryLib changes. > > I'm happy to throw it away next week if we can get something better in > > by then. > > > >> The AArch64 optdxe changes i proposed are arguably as harmless, > > > > Yes, but that leaves ARM broken. > > Not necessarily. ARM can use the generic BaseMemoryLib in MdePkg OK, but that's still yet another change. > >> since they don't affect any other arch either. And the stm aarch64 > >> versions are plain c to begin with > > > > And I want to discuss that next week. Against the backdrop of a > > working master branch. > > My concern is that having an 'ARM' flavor of BaseMemoryLib in MdePkg/ > will make it more difficult rather than easier to simply add ARM > support to the existing non-sse/mmx ones I don't share that concern. I am entirely serious about nuking it next week if we come to an agreement on a better solution. And I'm happy to take on the drudgery of fixing up all the platforms. (As a side note, this is an excellent example of why we need to create reusable config fragments - fixing all ARM platforms to use the correct library should be at most a two-liner in one place in edk2.) > Added the fact that the Stm is not in great shape, I would really > prefer to get rid of it rather than 'promote' it to the standard ARM > implementation. Note that we will need another round of updates to the > platform .DSCs when we remove the Stm version again. My main concern is leaving the master branch unusable for ARM during the Labor Day weekend. If we don't resolve this tonight, with the best will in the world we won't be back to a functioning master before Tuesday evening. / Leif