From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 CD0761A1E0A for ; Fri, 2 Sep 2016 11:11:04 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id c198so53107173ith.1 for ; Fri, 02 Sep 2016 11:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B7IMTNRlOQ7hgWzLRue2pZnWSwUFfuOKYS8QKCg8RGo=; b=Dft+FfmJyRqeme2XwFr2EsySSea8pL2hulheHywV5c/HK+8XwmTmMMx92Rvptpb3SB tfFN7omH1DPAJ8b+D08kBhz+ENE2oHrKiCK0xfQ9GAU0e2z7u9cH6GCfy1JRQXNShGSc RfWJESATkAn4cfjJf3X1rTHmxjDJ4tEsXiPZ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B7IMTNRlOQ7hgWzLRue2pZnWSwUFfuOKYS8QKCg8RGo=; b=OIwcnGCl3oQuUywEJAt5yXt2J/9RYZiaSQjPwTU/BYY5D31RXIKp57H+Dwc526G04S qwOej1maYVMmEvm+CTGDGrxaE8ZfdwyHtEwrIszru7qnX9gEYxkAWSz1DNX1RC0A9JEM UT4L7tfEc439s3HijGsI5mh1gU7lm8YVtdGKnlGolzJ/fwNldQlNVEhvKRYdV9ciWu4l H6GDOB817olBBnrDXry+Ei082paQCNK5C/eTfNOdxqMSwK/3xohrplb3G/KM0Effa1u8 ZDt4IzlMI+iGekvV/mvwtfYUzWNpTIRrmbKKEk4OCk44LLxRosWryWG+ghtTiw8PjmD3 TAGg== X-Gm-Message-State: AE9vXwP5ziBhzgS8l7sINcCPg8WFMTivsaZTVvuU5N2PazpdvXolAc9jKmKtD5POnntum1kgLa99DBGN9POD3gy0 X-Received: by 10.36.107.211 with SMTP id v202mr6269656itc.51.1472839863215; Fri, 02 Sep 2016 11:11:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Fri, 2 Sep 2016 11:11:02 -0700 (PDT) In-Reply-To: <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> <20160902180513.GE4715@bivouac.eciton.net> From: Ard Biesheuvel Date: Fri, 2 Sep 2016 19:11:02 +0100 Message-ID: To: Leif Lindholm Cc: edk2-devel-01 , Laszlo Ersek , Michael D Kinney , Liming Gao 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:11:05 -0000 Content-Type: text/plain; charset=UTF-8 On 2 September 2016 at 19:05, Leif Lindholm wrote: > 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. > I agree that fixing the branch now would be nice. I just don't understand why fixing BaseMemoryLibStm in place is not a better solution, especially if we are nuking it anyway next week. That way, we have to change all the platforms only a single time.