svn commit: r334939 - head/stand/lua

Warner Losh imp at bsdimp.com
Mon Jun 11 18:20:22 UTC 2018


On Mon, Jun 11, 2018 at 11:54 AM, Devin Teske <dteske at freebsd.org> wrote:

>
> On Jun 11, 2018, at 7:07 AM, Warner Losh <imp at bsdimp.com> wrote:
>
>
>
> On Mon, Jun 11, 2018 at 7:36 AM, Devin Teske <dteske at freebsd.org> wrote:
>
>>
>>
>> > On Jun 10, 2018, at 6:32 PM, Kyle Evans <kevans at FreeBSD.org> 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’re 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 while
>> also having the image ability to induce vomiting 🤮 by the uninitiated.
>>
>> However, all that being said, I’d 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’t know the power that
>> ficl4 brings — 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
>> network 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,
> and we plan to remove FORTH in 13. Last time I said it there in February,
> there 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 those
> plans.
>
>
> At BSD Can there was the boot working group where we discussed that an FCP
> would be required to decide this.
>

In the working group you weren't listening and being rather combative and
demanding that I do stuff, so I stopped talking. 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 been settled months ago.

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 between
> 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
> which 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 to
> 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 at .
I originally pitched coexistence, but there was little appetite for that.

So I think a FCP discussed in arch@ is the right path forward.

Warner


More information about the svn-src-head mailing list