From owner-svn-src-head@freebsd.org Tue Jun 12 00:44:13 2018 Return-Path: Delivered-To: svn-src-head@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 69392101884A; Tue, 12 Jun 2018 00:44:13 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1876A88A19; Tue, 12 Jun 2018 00:44:13 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id A9E3217DEF; Tue, 12 Jun 2018 00:44:12 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f54.google.com with SMTP id y20-v6so33366356lfy.0; Mon, 11 Jun 2018 17:44:12 -0700 (PDT) X-Gm-Message-State: APt69E22T7VAZOoqrKzjKVaaSnjcd920qucGssDAIJe/+zxUEHIsRnUA ARiRCr21T6dWDZCI0WvFCHZtofe4Er2jEtzDFy4= X-Google-Smtp-Source: ADUXVKL4HchUtEqBEc5z1AUb1rbKI90VVx4abxCK2SPsx1LOlVjyQp1x5ASys8B6QHcrz39RH8JAHrkLGjmDgJUbTAM= X-Received: by 2002:a2e:575c:: with SMTP id r28-v6mr784328ljd.51.1528764251372; Mon, 11 Jun 2018 17:44:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:2b92:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 17:43:50 -0700 (PDT) In-Reply-To: <81AF4479-3B71-420F-90C7-06ED64007F52@FreeBSD.org> References: <201806110132.w5B1WI5d094546@repo.freebsd.org> <344AA709-2DF7-405C-AB4D-4F0978834EA1@FreeBSD.org> <81AF4479-3B71-420F-90C7-06ED64007F52@FreeBSD.org> From: Kyle Evans Date: Mon, 11 Jun 2018 19:43:50 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r334939 - head/stand/lua To: Devin Teske Cc: Warner Losh , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 00:44:13 -0000 On Mon, Jun 11, 2018 at 7:34 PM, Devin Teske wrote: > > On Jun 11, 2018, at 5:32 PM, Kyle Evans wrote: > > On Mon, Jun 11, 2018 at 7:23 PM, Devin Teske wrote: > > > On Jun 11, 2018, at 11:20 AM, Warner Losh wrote: > > > > On Mon, Jun 11, 2018 at 11:54 AM, Devin Teske wrote: > > > > On Jun 11, 2018, at 7:07 AM, Warner Losh wrote: > > > > On Mon, Jun 11, 2018 at 7:36 AM, Devin Teske wrote: > > > > > On Jun 10, 2018, at 6:32 PM, Kyle Evans wrote: > > Author: kevans > Date: Mon Jun 11 01:32:18 2018 > New Revision: 334939 > URL: https://svnweb.freebsd.org/changeset/base/334939 > > Log: > lualoader: Allow brand-*.lua for adding new brands > > dteske@, I believe, had originally pointed out that lualoader failed > to > allow logo-*.lua for new logos to be added. When correcting this > mistake, I > failed to do the same for brands. > > > You=E2=80=99re doing an amazing job, Kyle. > > I continually see nothing but genuine effort toward feature parity which > makes me think one day I can pass the reigns. > > Yeah, I will always love Forth. It will always hold a special place in my > heart as that whacky language that simultaneously exudes great power whil= e > also having the image ability to induce vomiting =F0=9F=A4=AE by the unin= itiated. > > However, all that being said, I=E2=80=99d actually like to keep the Ficl = boot > stuff as an option through to 14.0 and here is why ... > > Last year we were looking to update from ficl3 to ficl4. That may not > sound too exciting to most folks, but most folks don=E2=80=99t know the p= ower that > ficl4 brings =E2=80=94 like the capability to use full networking in the = loader! Can > lua do that? How cool would it be to be able to communicate with the netw= ork > from the loader before the kernel is even loaded into memory? I had a few > hair-brained schemes left for Forth which might be exciting, lol > > > > The current boot loader can already communicate via NFS or TFTP today. > Adding http would be easy, https would be harder due to crypto being huge > and space being small (though bear ssl might be small enough). > > The last articulated plan in arch@ was that LUA will be default in 12, an= d > we plan to remove FORTH in 13. Last time I said it there in February, the= re > was only email agreeing that I could find. This matches the in-person > consensus poll I took at BSDcan as well. I think it would take a very > extraordinary set circumstance and severe problems with LUA to change tho= se > plans. > > > At BSD Can there was the boot working group where we discussed that an FC= P > would be required to decide this. > > > > In the working group you weren't listening and being rather combative and > demanding that I do stuff, > > > I think that's an unfair characterization of the situation, but it doesn'= t > matter -- that's your opinion and you are entitled to it. > > > > so I stopped talking. > > > Hopefully we can _start_ talking. As the principled author of this work, = I > want to have a say in its deprecation since I still maintain that body of > work. > > > It should not be taken as a sign of my consent, but more a sign of not > wanting to get into a yelling match in public on a topic I thought had be= en > settled months ago. > > > Nobody asked *me* about how I would like to see *my* work removed from th= e > tree. I think I should have a say. > > I think I've been pretty darn helpful in the process by providing > substantive and helpful feedback to not only Kyle but also on the GSoC > project etc. I've not stood in any ones way. For being so helpful, I woul= d > expect a level respect in this matter. > > > > I raised my desires that I would like to be able to flip a knob in 13 and > reboot between Ficl and Lua, back and forth. > > Give people a choice until we have done a "shake-out" through an entire > major version. > > An honest-to-goodness procession would be, in my mind: > > 13: Has both; both are installed. End-user can boot back and forth betwee= n > the two > > Problems that arise in one or the other are non-critical because there is > always an "out" by running the other. > > 14: Has both but both are not installed. The installer media doesn't even > have it. You can't install the Forth booth stuff unless you twist a knob = in > buildworld, optionally going down the path of generating release media wh= ich > has the Forth boot stuff. > > 15. It's removed from tree. You can't build Forth boot. Lua only. No > looking back, no way to build it with Forth, to get Ficl you need to go t= o > ports. A Ficl with FreeBSD boot words no longer exists and is no longer > maintained. All of bhyve userboot also therefore uses Lua. > > > > That's way too long. 12 will have Lua by default, but you can build FORTH= if > you want has been the plan since February when I socialized this on arch@= . I > originally pitched coexistence, but there was little appetite for that. > > So I think a FCP discussed in arch@ is the right path forward. > > > We sat on the GSoC for years. Why all of a sudden do we need to ship this= in > less than 6 months? > > There are new features in Forth for 12 and they work and Lua has not caug= ht > up to them (e.g., Boot Environments in the loader menu) and you want to m= ake > Lua the default in 12? This doesn't make sense. > > > I have no comments on the rest- this discussion should mostly occur on > the FCP that will be drafted shortly. We added Boot Environment > support months ago at this point, and also added some other cool > feature like auto-detecting kernels in /boot/* to be presented in the > kernel selector. > > > Would you be willing to update here for the benefit of those in this > thread... > > Are you at feature parity yet? Basically, yeah. There's a couple of environment variables not respected that I could easily implement given, say, an hour or two. OTOH, 'feature parity' is slightly rough to define as one has to weed out what still makes sense in the Lua-based world vs. what gets a more Lua-ish way of accomplishing the same task (e.g. with menu stuff).