From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 D444521A04823 for ; Tue, 11 Apr 2017 14:13:17 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id w64so73519925wma.0 for ; Tue, 11 Apr 2017 14:13: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=HwA637SX+AfNHxg/Z4R2tyR5Ldq6CWzynVBkKGSWh/k=; b=C7gq/Zgn8Phcl0eWdNb+zwsOU5/hl2j0mz99tZhxHl9+RBve59DQGZaX3r9TvIJLoi WnlfwOCKCPzaUjU+gRWomwj2yeu4Mf2nPeRImxZ6M0/a31umFfeRAokAcfUeu2IzzGT7 pJWf+XoDDfepNge5ar2t+bv+RPu9Qnzt7M5fc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=HwA637SX+AfNHxg/Z4R2tyR5Ldq6CWzynVBkKGSWh/k=; b=HbLQM01Ip0Ep1ViS1tadbt6/G0LUCus3PFezW0iogmQJhMqF8tR4noyQqjbG6wxDLD NnXEsYJwC83SfD+Wy69k+ZY37aTF7PQrZEv417VHFFQD0eRmQED7UnTbSOPcI/jpGZ// bbsNkaF/S6nfis22xQZaJps+VUTZnPTaFiZpXUXjFDqMzLiSczFC2cYewukymWJXwGrz 8dQgdtHFok/jE5cc9Ypg8LZPaIXSgUAa2We6uxa/664OdrK+840VHR3dNoe5RaiZolxe kuRCCSFkjw/R4+RYDSFNGLuAvcoidIr3gvuE7ZAuZNh3cJhbHmSGR3NtUx+9PJ3hpBhX hNug== X-Gm-Message-State: AN3rC/47Ya8Zmg3Bm0g+c0qn3daGHVQ1OfDBE5t3CRkUTuxcKizYGf6b6JQbS8WGmcLf+AQR X-Received: by 10.28.206.195 with SMTP id e186mr11324900wmg.37.1491945196373; Tue, 11 Apr 2017 14:13:16 -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 b10sm3924185wme.22.2017.04.11.14.13.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 14:13:15 -0700 (PDT) Date: Tue, 11 Apr 2017 22:13:13 +0100 From: Leif Lindholm To: Andrew Fish Cc: edk2-devel@lists.01.org, Chenhui Sun , Marcin Wojtas , Evan Lloyd , Ard Biesheuvel Message-ID: <20170411211313.GX1657@bivouac.eciton.net> References: <20170411094430.GT1657@bivouac.eciton.net> <847AC2FB-E4AC-4722-8B01-0FA88E59C248@apple.com> MIME-Version: 1.0 In-Reply-To: <847AC2FB-E4AC-4722-8B01-0FA88E59C248@apple.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: Future of EBL (is there one?) X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 21:13:18 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Andrew, On Tue, Apr 11, 2017 at 07:57:13AM -0700, Andrew Fish wrote: > > On Apr 11, 2017, at 2:44 AM, Leif Lindholm wrote: > > This email was brought about by Ard's spring cleaning. > > > > EBL (EmbeddedPkg/Ebl/) is (to the best of my understanding) a sort of > > lightweight alternative to UEFI Shell, especially for serial console > > only embedded devices. > > > > Leif, > > I wrote the original code something like 10 years ago. The intent > was a proof of concept that EFI could scale down to embedded systems > and be a BSD licensed alternative to U-Boot. I was trying to show > that implementation != architecture and a lot of edk2 projects were > large but they did not have to be. > > I was kind of surprised how popular it was and how many products > actually shipped with it. I'm fine with deprecating the EBL if it > makes sense. Thanks. For what it's worth - I think it's worth revisiting that in the future, combined for lightweight ARM and x86 platforms (and maybe RISC-V), and through the magic of git it will be easy to resurrect at that point. For now, I mainly want to stop new platform ports being posted with both EBL and UEFI Shell. (And I've not seen any using EBL for a good reason in a long time.) Regards, Leif. > > Thanks, > > Andrew Fish > > > Probably because this was included in some existing ARM platforms in > > the past, and its monolithic design made it more familiar to embedded > > firmware developers to plug new commands into than the (extremely > > modular) Shell, this has now made it into several > > definitely-not-embedded platform ports. > > > > In order to reduce the risk of this happening again, I would like to > > consider the option of deleting EBL. > > > > Do we still have a need for EBL in EDK2? > > If so, can someone give a descriptive mission statement for it? What > > is it intended for, and what does it provide over the alternatives? > > > > For those on cc who have included it in platform ports (in > > OpenPlatformPkg), can you explain why? > > > > Evan - is EBL of any interest to your team? > > > > Regards, > > > > Leif >