From owner-freebsd-current@freebsd.org Mon Feb 12 18:47:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90232F114F5 for ; Mon, 12 Feb 2018 18:47:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2054D84F87 for ; Mon, 12 Feb 2018 18:47:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 2B27810A8BE; Mon, 12 Feb 2018 13:47:18 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Cc: Warner Losh Subject: Re: LUA boot loader coming very soon Date: Mon, 12 Feb 2018 09:12:27 -0800 Message-ID: <2333272.J6kp8cXjfh@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 12 Feb 2018 13:47:18 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 18:47:24 -0000 On Monday, February 12, 2018 08:27:27 AM Warner Losh wrote: > Greetings, > > As you may know, the Lua (http://www.lua.org) boot loader has been in the > works for some time. It started out life as a GSoC in 2014 by Pedro Souza > mentored by Wojciech A. Koszek. Rui Paulo created a svn project branch to > try to integrate it. I rebased that effort into a github branch which Pedro > Arthur fixed up. Over the past year, I've been cleaning up the boot loader > for other reasons, and found the time was ripe to start integrating this > into the tree. However, those integration efforts have taken a while as my > day-job work on the boot loader took priority. In the mean time, Ed Maste > and the FreeBSD Foundation funded Zakary Nafziger to enhance the original > GSoC Lua scripts to bring it closer to parity with the evolution of the > FORTH menu system since the GSoC project started. > > I'm pleased to announce that all these threads of development have > converged and I'll be pushing the FreeBSD Lua Loader later today. This > loader uses Lua as its scripting language instead of FORTH. While > co-existance is planned, the timeline for it is looking to be a few weeks > and I didn't want to delay pushing this into the tree for that. > > To try the loader, you'll need to build WITHOUT_FORTH=yes and > WITH_LOADER_LUA=yes. Fortunately, you needn't do a full world to do this, > you can do it in src/stand and install the result (be sure to have the > options for both the build and the install). This will replace your current > /boot/loader that is scripted with FORTH to one that's scripted with Lua. > It will install the lua scripts in /boot/lua. The boot is scripted with > /boot/lua/loader.lua instead of /boot/loader.rc. You are strongly advised > to create a backup copy of /boot/loader before testing (eg cp /boot/loader > /boot/loader_forth), since you'll need to boot that from boot2 if something > goes wrong. I've tested it extensively, though, with userboot.so and it's > test program, so all the initial kinks of finding the lua scripts, etc have > been worked out. > > While it's possible to build all the /boot/loader variants with Lua, I've > just tested a BIOS booting /boot/loader both with and without menus > enabled. I've not tested any of the other variants and the instructions for > testing some of them may be rather tedious (especially UEFI, if you want a > simple path to back out). Since there's not been full convergence testing, > you'll almost certainly find bumps in this system. Also, all the > build-system APIs are likely not yet final. > > I put MFC after a month on the commit. Due to the heroic (dare I say > almost crazy) work of Kyle Evans on merging all the revs from -current to > 11, I'm planning a MFC to 11 after the co-existence issues are hammered > out. In 11, FORTH will be the default, and Lua will be built by default, > but users will have to do something to use it. 12, both FORTH and Lua will > be built and installed, with Lua as default (barring unforeseen > complications). Once the co-existence stuff goes in, I imagine we'll make > the switch to Lua by default shortly after that. In 13, FORTH will be > removed unless there's a really really compelling case made to keep it. > > So please give it a spin and give me any feedback, documentation updates > and/or bug fixes. I'm especially interested in reviews from people that > have embedded Lua in other projects or experts in Lua that can improve the > robustness of the menu code. Do you have some memory usage numbers for LUA vs forth for the different BIOS loaders (text/data/bss sizes)? For the EFI case we probably have lots of room, but for the non-EFI case we are constrained to 0xa0000 - 0xa000 for the text/data/bss and stack (in some cases like PXE booting the top can be lower than 0xa0000). I'm not sure if we have any other platforms with similar memory constraints. -- John Baldwin