From owner-freebsd-current@freebsd.org Tue Feb 20 02:23:54 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 B94C7F19F89 for ; Tue, 20 Feb 2018 02:23:54 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from shxd.cx (mail.shxd.cx [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5698F7A637; Tue, 20 Feb 2018 02:23:54 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from [172.58.145.77] (port=49224 helo=[IPv6:2607:fb90:58f7:47fc:d1cc:63a6:1309:bd22]) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1enwNk-000Cfn-Ma; Tue, 20 Feb 2018 01:06:09 +0000 Mime-Version: 1.0 (1.0) Subject: Re: ACPI panic on boot with new Lua loader and other minor issues From: Devin Teske X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Mon, 19 Feb 2018 20:23:47 -0600 Cc: Kyle Evans , =?utf-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= , FreeBSD Current , dteske@FreeBSD.org Message-Id: References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> <6EB9705C-92AC-4952-B1F6-642DCD4701F1@freebsd.org> To: Warner Losh Sender: devin@shxd.cx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Tue, 20 Feb 2018 02:23:55 -0000 > On Feb 19, 2018, at 4:32 PM, Warner Losh wrote: >=20 >=20 >=20 >> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske wrote: >>=20 >>=20 >> > On Feb 19, 2018, at 2:21 PM, Kyle Evans wrote: >> > >> > It seems that the Forth loader might be doing something sneaky and >> > replacing the standard common "boot" with a Forth boot that handles >> > this a lot better. CC'ing dteske@ so they can confirm. >>=20 >> I can indeed confirm this as fact. >>=20 >> Not able to help much because I am driving cross-country (San Francisco t= o Orlando) right now with the spouse and dog. >>=20 >> We get back March 3rd, but I will be checking-in from time to time for sp= oradic responses during downtime. >=20 > The command in loader.4th is defined as: >=20 > : boot > 0=3D if ( interpreted ) get_arguments then >=20 > \ Unload only if a path was passed > dup if > >r over r> swap > c@ [char] - <> if > 0 1 unload drop > else > s" kernelname" getenv? if ( a kernel has been loaded ) > try-menu-unset > bootmsg 1 boot exit > then > load_kernel_and_modules > ?dup if exit then > try-menu-unset > bootmsg 0 1 boot exit > then > else > s" kernelname" getenv? if ( a kernel has been loaded ) > try-menu-unset > bootmsg 1 boot exit > then > load_kernel_and_modules > ?dup if exit then > try-menu-unset > bootmsg 0 1 boot exit > then > load_kernel_and_modules > ?dup 0=3D if bootmsg 0 1 boot then > ;=20 >=20 > The thing to know here is when you see 'boot' as part of above script, it'= s calling the 'boot' cli command, not itself recursively. >=20 What is actually going on is that when the =E2=80=9Cboot=E2=80=9D function i= s compiled, the reference to =E2=80=9Cboot=E2=80=9D inside it is to the alre= ady-existing word defined previously. Forth allows you to have multiply-defi= ned names. The =E2=80=9Cboot=E2=80=9D command inside the =E2=80=9Cboot=E2=80= =9D function is replaced with the address of previous boot during function c= ompilation because the function is m not defined and given an address in the= dictionary until it is completed (last line compiled). =E2=80=94=20 Devin=