From owner-freebsd-arch@freebsd.org Tue Feb 6 00:39:38 2018 Return-Path: Delivered-To: freebsd-arch@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 136ECEDC9C4 for ; Tue, 6 Feb 2018 00:39:38 +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 B61A86A144; Tue, 6 Feb 2018 00:39:37 +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 AE9F110A8BA; Mon, 5 Feb 2018 19:39:31 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Cc: Warner Losh , Devin Teske , Poul-Henning Kamp , Devin Teske Subject: Re: Feedback on proposed loader changes Date: Mon, 05 Feb 2018 16:38:31 -0800 Message-ID: <11401110.65I9PsZnfs@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: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 05 Feb 2018 19:39:31 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 00:39:38 -0000 On Thursday, February 01, 2018 10:59:14 AM Warner Losh wrote: > On Thu, Feb 1, 2018 at 9:58 AM, Devin Teske wrote: > > And as the principal author of the Forth menu since 9.0: > > > > 3. Please give me a way to run my code (at the very least until I c= an > > bring the Lua up to snuff; and if I can=E2=80=99t just let me run F= orth > > in-perpetuity). > > > > Interrupting boot1 so I can drive the system in the pre-boot Execut= ion env > > is very important to me. >=20 >=20 > For !EFI, this is relatively easy. boot1 you can type /boot/loader_fo= rth > instead of the default /boot/loader if the symlink changes and you wa= nt to > go back. >=20 > For EFI the answer is more complicated. boot1.efi is going away, so > loader.efi will move to the ESP in \efi\freebsd\loader.efi, but it's = easy > enough to have multiple versions there (loader_lua.efi and > loader_forth.efi) and select via EFI Shell or EFI Env variables which= one > you want should you need to fall back. >=20 > Does that answer your concerns? I think there is an even easier route for doing scripted loader develop= ment now: Use bhyve with bhyveload. You get to run the loader as a plain us= erland program (so you can use normal debuggers on it while it is running) whi= le being able to test all the menu features. You can even make it use the= builtin host: filesystem without requiring a disk image so you can modi= fy the lua files directly on the host that are getting pulled in for a fast edit-debug cycle. --=20 John Baldwin From owner-freebsd-arch@freebsd.org Wed Feb 7 12:41:18 2018 Return-Path: Delivered-To: freebsd-arch@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 1FF71F02DFA for ; Wed, 7 Feb 2018 12:41:18 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id B6F9D875F7 for ; Wed, 7 Feb 2018 12:41:17 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 1AFA627BE for ; Wed, 7 Feb 2018 12:41:17 +0000 (UTC) Subject: Re: Feedback on proposed loader changes To: freebsd-arch@freebsd.org References: From: Eric McCorkle Message-ID: <2c882f57-def0-b9f1-3c62-147cbe6bec02@metricspace.net> Date: Wed, 7 Feb 2018 07:41:15 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 12:41:18 -0000 Might I suggest we integrate the GELI work before this goes in? It can be added to loader as-is, and it works fine if you apply my standalone loader patch (I have it deployed on a personal laptop). I'm on the third major revision of this work (with countless smaller rebases), and I'd like to not have to redo it a fourth time. Basically, you'd need to commit some fixes to the efipart driver, the UEFI KMS driver, the keybuf integration, and finally, the GELI driver itself. I doubt this would interfere with 4th replacement, but I'd like to not have this stuff get hit by stray changes. On 02/01/2018 00:03, Warner Losh wrote: > Greetings, > > As you may have read or guessed, I'm nearing the end game on integrating > lua into the boot loader from the GSoC a few years ago. I've tried to > resolve all the issues it brought up in libsa and other structural changes. > This has allowed lua to be imported unmodified, for example. > > I've been trying to figure out how to handle the transition from forth to > lua and find myself with a few decisions that I should seek feedback on > since I'm at a crossroads. > > The first one is that we have two sets of 4th words, both of which I wrote, > that don't fit neatly into the current build system. We have a bit of a > hack in place for both the pcibios-* and efi-* functions in 4th. The former > was something I did as a hack for Netflix that I judged at the time to be > more useful than it turned out to be (as far as I've been able to tell). > The latter turns out to be a road not taken (I'd planned originally on > implementing UEFI boot manager with 4th, but that turns out to be not > desirable even if 4th might be out the door). My plan is to simply retire > this stuff, along with pnp.4th which we've never installed. If I do this, > then I can build everything in the tree w/o regard to whether FORTH is on > or off, which dove tails nicely to my next question... > > If no .o depends on the interpreter we're using (other than the ones that > implement the interpreter), then there'd be no technical barrier to > building multiple interpreters. So, I'd like to change to building both > the loader with forth and the one without, as well as installing both (as > loader_simple and loader_forth) with a symlink to the default. This would > allow people to switch, as well as provide a fallback for most systems > (uboot on FAT would be trickier, but we don't directly install those from > installworld, EFI on FAT would be as well, but there it will matter much > less shortly). This would allow me to roll out loader_lua when it's ready > and have it installed everywhere for people that want to take the plunge > and switch it when the time is ripe. This path would also leave the old > boot loaders around for people to interrupt boot1 with (EFI is another > matter, but I'm hoping efibootmgr wills solve that ball of wax). > > So I'd like feedback on two questions: Should I kill the forth features I > oulined above? And should I make the build system build multiple loaders > with a link controlling the default? > > Comments? > > Warner > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Wed Feb 7 15:54:07 2018 Return-Path: Delivered-To: freebsd-arch@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 254DFF105CE for ; Wed, 7 Feb 2018 15:54:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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)) by mx1.freebsd.org (Postfix) with ESMTPS id A891A6F6B5 for ; Wed, 7 Feb 2018 15:54:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id k131so2805803ith.4 for ; Wed, 07 Feb 2018 07:54:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wxHvVugL5C92XORcr9StbpNK6+BH0Sp/dpHar6ZuwCQ=; b=phUvuuuX31cM0rsr9D4dxupoRHKZF51e0zuTtOUmaN45RMxdfltds30TbL5MUquPRR PIWIngFeyDjolsxu2jsYHFk7OcVJkWuSjAAicUsSb8ZDdicFN3OvVqSxfmlrI1dEnG/9 aj01vyixS4MjG0XIMUyLqYjOnlIL81sMfAf7Avg4v/I8IDDiG0y7AClJgu79nc8wBAHt uf+18Nzea0WvyDoRc+hYX+IdBvZJwVSkQrI++NeDUBpF5mM9d5KhxFeJ0nfduGho2fhP 1LPSPiRuJBCLXcwfRc/oDVFSl2qFuMO0V/6xFUb0/+8Va/L4bT61Yrawkx/vFz0iyxv4 tm3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wxHvVugL5C92XORcr9StbpNK6+BH0Sp/dpHar6ZuwCQ=; b=XF9vd0tgZl4d0ZiimGJGtGikwe/gunOYR3PNqb8tURWSLarhyVFQSpCrf1wLHEah3f sQKeg+yyg2InTjdOKxbRo6XaoCk/5acdUYKIwJBPcDE0cp7fdp4+19cj3IgecxPkb76T 1CVWGSKi8DJIHsIokInGQE++NBC25o5CopTexTNZks3nW1DP9dVbZbeizSP2M1TjVoJ9 8E3p4gCeBP97PxmB8mah6qC9ggm9roAns5TZZR0sG9N0H70hd08Ijb+E9TyF3X2iuFK9 D/srYH9cd/29ZsPhKNYuWzDL8bJOoxHCMg4TDuCbRSLHqi1oXLZj+DUSu4oewuAJ35yK kKRQ== X-Gm-Message-State: APf1xPDlYpJFL9W1YCYplIraw4RbRTAmPvcno5T+C9kOSeZYJZKknonN 9k1gPuEnA+SrSGEL+0Pnp6YPhW3VP0/N402GUEFbeA== X-Google-Smtp-Source: AH8x225Duv1teNpUns1luGZLDcExYQl2ARMA7+v2GUtr4hBB8VwnUS5F46XeCj7AQEIrIp5f5PaO5nnz/R8nUk+lTOE= X-Received: by 10.36.250.193 with SMTP id v184mr8112026ith.64.1518018845919; Wed, 07 Feb 2018 07:54:05 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Wed, 7 Feb 2018 07:54:05 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <2c882f57-def0-b9f1-3c62-147cbe6bec02@metricspace.net> References: <2c882f57-def0-b9f1-3c62-147cbe6bec02@metricspace.net> From: Warner Losh Date: Wed, 7 Feb 2018 08:54:05 -0700 X-Google-Sender-Auth: a7jGJ4iEG7vq4UQ05g8RqzWOOY0 Message-ID: Subject: Re: Feedback on proposed loader changes To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 15:54:07 -0000 I'm afraid not. There's still unresolved issues in the efipart driver changes in the reviews that tsoome raised, so it isn't ready. Lua is 3 commits away and is to the point where all the refinement of those three changes is in code that's not in the tree yet. It goes in first, hopefully this week. I doubt there will be any affect on your ongoing work. Warner On Wed, Feb 7, 2018 at 5:41 AM, Eric McCorkle wrote: > Might I suggest we integrate the GELI work before this goes in? It can > be added to loader as-is, and it works fine if you apply my standalone > loader patch (I have it deployed on a personal laptop). > > I'm on the third major revision of this work (with countless smaller > rebases), and I'd like to not have to redo it a fourth time. > > Basically, you'd need to commit some fixes to the efipart driver, the > UEFI KMS driver, the keybuf integration, and finally, the GELI driver > itself. I doubt this would interfere with 4th replacement, but I'd like > to not have this stuff get hit by stray changes. > > On 02/01/2018 00:03, Warner Losh wrote: > > Greetings, > > > > As you may have read or guessed, I'm nearing the end game on integrating > > lua into the boot loader from the GSoC a few years ago. I've tried to > > resolve all the issues it brought up in libsa and other structural > changes. > > This has allowed lua to be imported unmodified, for example. > > > > I've been trying to figure out how to handle the transition from forth to > > lua and find myself with a few decisions that I should seek feedback on > > since I'm at a crossroads. > > > > The first one is that we have two sets of 4th words, both of which I > wrote, > > that don't fit neatly into the current build system. We have a bit of a > > hack in place for both the pcibios-* and efi-* functions in 4th. The > former > > was something I did as a hack for Netflix that I judged at the time to be > > more useful than it turned out to be (as far as I've been able to tell). > > The latter turns out to be a road not taken (I'd planned originally on > > implementing UEFI boot manager with 4th, but that turns out to be not > > desirable even if 4th might be out the door). My plan is to simply retire > > this stuff, along with pnp.4th which we've never installed. If I do > this, > > then I can build everything in the tree w/o regard to whether FORTH is on > > or off, which dove tails nicely to my next question... > > > > If no .o depends on the interpreter we're using (other than the ones that > > implement the interpreter), then there'd be no technical barrier to > > building multiple interpreters. So, I'd like to change to building both > > the loader with forth and the one without, as well as installing both (as > > loader_simple and loader_forth) with a symlink to the default. This would > > allow people to switch, as well as provide a fallback for most systems > > (uboot on FAT would be trickier, but we don't directly install those from > > installworld, EFI on FAT would be as well, but there it will matter much > > less shortly). This would allow me to roll out loader_lua when it's ready > > and have it installed everywhere for people that want to take the plunge > > and switch it when the time is ripe. This path would also leave the old > > boot loaders around for people to interrupt boot1 with (EFI is another > > matter, but I'm hoping efibootmgr wills solve that ball of wax). > > > > So I'd like feedback on two questions: Should I kill the forth features I > > oulined above? And should I make the build system build multiple loaders > > with a link controlling the default? > > > > Comments? > > > > Warner > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Wed Feb 7 16:04:14 2018 Return-Path: Delivered-To: freebsd-arch@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 BC24FF111BD for ; Wed, 7 Feb 2018 16:04:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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)) by mx1.freebsd.org (Postfix) with ESMTPS id 505886FF87 for ; Wed, 7 Feb 2018 16:04:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id i144so2857767ita.3 for ; Wed, 07 Feb 2018 08:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Fx/tvUYaeHCdjbWDsbC3+8py4KyPQ+CW4TcJKrCilBQ=; b=uomFU5Q9RfTCLzu1Np5p2NtUgAcqf7Fgav+gzhNIh2WpmBPNqsoi1wcamlRsNVtTK6 ULgp4S0dsT6RuACdql86loqBSzx/Kwxjo9qvs5m2eFY2zr1OxiSFCq95w/TIBHdILOvr Trjhhp+4GHk1pDcjZEb8VBBVGCsY6BYQpLjgpeDv7FWPaxtCZ//X3jeXUqhIYmfk2Zu+ WvzDTYVEcvFSWdjK0jjknUS+rwLNlLiBBHFxQgrrPUm8eggbMEr1tOugppT0CXYmTMxa RdMHO0+GUzypmXaWI/1VtX/eav3Yv7L4HYTDsS9+V2LCGh9+CCVCclQnXiUluXehiXYX 0Q1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Fx/tvUYaeHCdjbWDsbC3+8py4KyPQ+CW4TcJKrCilBQ=; b=iFLQFrH3lX0v4W/DoBrWp0p/1gmZ9hZ5dAudLlfGf7jAleUS0iBimVCZda8DCYIgvp fCmZ4fQIgkCXEMi8IFzHWhL21Ou4IN5mlPYqCAjlqM7oMFLZI4eu8vxKI1/XioxKHOyE EHL8z+8HRsgBI8vZMwBRFgnpvwvFMXfolEZPq2vrtmawUkoerAiSbx6mQcLpuFMkMdbZ 6yhM9dTr1ay7p9S4+qHZEmoNH2vtkYH442KMEZazyMjdnayyUmYSXyarBItS5PFQgDq+ k/bYyUEBu2USyjmp1SiA32PyEQEcgaM0907I4GOWJIbBfcl+6dLKWHTPri87hUe0/ft3 nGbw== X-Gm-Message-State: APf1xPBYbIp8tUvaZHsufIgQSw+p0+eC273Jb/EWeg+OFog3yeUd+L4L qiQ6SfvcGXgl4n6AcMNRe/jw9YYIwSZNSzT+UnrTWA== X-Google-Smtp-Source: AH8x224cQJ/FQMYKBPGJDXEaWj5EkqMLljXZgjdBE3LYqBgIdvthdxuE23HLryAQIsSCHDwZZmEku2b5Oa4ijtSShhY= X-Received: by 10.36.145.139 with SMTP id i133mr1609141ite.69.1518019453479; Wed, 07 Feb 2018 08:04:13 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Wed, 7 Feb 2018 08:04:12 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <2c882f57-def0-b9f1-3c62-147cbe6bec02@metricspace.net> From: Warner Losh Date: Wed, 7 Feb 2018 09:04:12 -0700 X-Google-Sender-Auth: _yrnZPtIjPgal8jNZyvoVt_b9hs Message-ID: Subject: Re: Feedback on proposed loader changes To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:04:15 -0000 Just re-read what I posted, and I need to followup. I should add at least some of your other changes are somewhat close. I'll do those before my pending efi boot loader changes. Any rework I have on them would be on me. I'm not sure how to address tsoome's concerns, though, since they are rather fundamental to the other work, so I can't fix that on the way in. So it isn't quite as harsh as I think my original message sounds. As for redoing things, I've just finished redoing ~15-years of sys/boot neglect for stuff that wasn't done right the first time, so please be patient with my pickiness. Warner On Wed, Feb 7, 2018 at 8:54 AM, Warner Losh wrote: > I'm afraid not. There's still unresolved issues in the efipart driver > changes in the reviews that tsoome raised, so it isn't ready. Lua is 3 > commits away and is to the point where all the refinement of those three > changes is in code that's not in the tree yet. It goes in first, hopefully > this week. I doubt there will be any affect on your ongoing work. > > Warner > > > On Wed, Feb 7, 2018 at 5:41 AM, Eric McCorkle > wrote: > >> Might I suggest we integrate the GELI work before this goes in? It can >> be added to loader as-is, and it works fine if you apply my standalone >> loader patch (I have it deployed on a personal laptop). >> >> I'm on the third major revision of this work (with countless smaller >> rebases), and I'd like to not have to redo it a fourth time. >> >> Basically, you'd need to commit some fixes to the efipart driver, the >> UEFI KMS driver, the keybuf integration, and finally, the GELI driver >> itself. I doubt this would interfere with 4th replacement, but I'd like >> to not have this stuff get hit by stray changes. >> >> On 02/01/2018 00:03, Warner Losh wrote: >> > Greetings, >> > >> > As you may have read or guessed, I'm nearing the end game on integrating >> > lua into the boot loader from the GSoC a few years ago. I've tried to >> > resolve all the issues it brought up in libsa and other structural >> changes. >> > This has allowed lua to be imported unmodified, for example. >> > >> > I've been trying to figure out how to handle the transition from forth >> to >> > lua and find myself with a few decisions that I should seek feedback on >> > since I'm at a crossroads. >> > >> > The first one is that we have two sets of 4th words, both of which I >> wrote, >> > that don't fit neatly into the current build system. We have a bit of a >> > hack in place for both the pcibios-* and efi-* functions in 4th. The >> former >> > was something I did as a hack for Netflix that I judged at the time to >> be >> > more useful than it turned out to be (as far as I've been able to tell). >> > The latter turns out to be a road not taken (I'd planned originally on >> > implementing UEFI boot manager with 4th, but that turns out to be not >> > desirable even if 4th might be out the door). My plan is to simply >> retire >> > this stuff, along with pnp.4th which we've never installed. If I do >> this, >> > then I can build everything in the tree w/o regard to whether FORTH is >> on >> > or off, which dove tails nicely to my next question... >> > >> > If no .o depends on the interpreter we're using (other than the ones >> that >> > implement the interpreter), then there'd be no technical barrier to >> > building multiple interpreters. So, I'd like to change to building both >> > the loader with forth and the one without, as well as installing both >> (as >> > loader_simple and loader_forth) with a symlink to the default. This >> would >> > allow people to switch, as well as provide a fallback for most systems >> > (uboot on FAT would be trickier, but we don't directly install those >> from >> > installworld, EFI on FAT would be as well, but there it will matter much >> > less shortly). This would allow me to roll out loader_lua when it's >> ready >> > and have it installed everywhere for people that want to take the plunge >> > and switch it when the time is ripe. This path would also leave the old >> > boot loaders around for people to interrupt boot1 with (EFI is another >> > matter, but I'm hoping efibootmgr wills solve that ball of wax). >> > >> > So I'd like feedback on two questions: Should I kill the forth features >> I >> > oulined above? And should I make the build system build multiple loaders >> > with a link controlling the default? >> > >> > Comments? >> > >> > Warner >> > _______________________________________________ >> > freebsd-arch@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-arch >> > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> > >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> > > From owner-freebsd-arch@freebsd.org Wed Feb 7 16:22:36 2018 Return-Path: Delivered-To: freebsd-arch@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 C2992F125A2 for ; Wed, 7 Feb 2018 16:22:36 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AFB170BD3; Wed, 7 Feb 2018 16:22:36 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (220-253-149-130.dyn.iinet.net.au [220.253.149.130]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w17GMTMd070380 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 7 Feb 2018 08:22:32 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Feedback on proposed loader changes To: Warner Losh , Devin Teske Cc: Poul-Henning Kamp , Devin Teske , "freebsd-arch@freebsd.org" References: <5015.1517478674@critter.freebsd.dk> From: Julian Elischer Message-ID: <2f744512-6ed1-eebf-7dba-ddba2786d4de@freebsd.org> Date: Thu, 8 Feb 2018 00:22:23 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:22:37 -0000 On 2/2/18 1:59 am, Warner Losh wrote: > On Thu, Feb 1, 2018 at 9:58 AM, Devin Teske wrote: > >> >>> On Feb 1, 2018, at 1:51 AM, Poul-Henning Kamp >> wrote: >>> -------- >>> In message > n3ESiUw@mail.gmail.com>, Warner Losh writes: >>>> So I'd like feedback on two questions: Should I kill the forth features >> I >>>> oulined above? And should I make the build system build multiple loaders >>>> with a link controlling the default? >>> I think you should just move forward and go for the end-stage >>> without too many temporary bandaids. >>> >>> The loader is pretty decoupled from everything, so in case anybody >>> needs any of these Forth cornercases, they can use 11.X loader with >>> very little, if any, trouble. >>> >> As a person that both reviewed the GSoC code you are working with >> (in-depth; including a list of short-comings) and the most likely person to >> bring it up-to-par after it is committed, I have 2 opinions: >> >> 1. Please allow both boot systems for a while so that the lua-based menu >> can be made as feature full as the Forth menu. Example: submenus were added >> in Forth long after the GSoC lua project had ended >> > OK. The plan outlined does that. The lua code will be installed into /boot. > But it will be .lua, so no conflicts with .4th. And we start from > loader.lua not loader.rc. > > >> 2. Please don’t force us to run Lua until I can code the new features >> > OK > > >> And as the principal author of the Forth menu since 9.0: >> >> 3. Please give me a way to run my code (at the very least until I can >> bring the Lua up to snuff; and if I can’t just let me run Forth >> in-perpetuity). >> >> Interrupting boot1 so I can drive the system in the pre-boot Execution env >> is very important to me. > > For !EFI, this is relatively easy. boot1 you can type /boot/loader_forth > instead of the default /boot/loader if the symlink changes and you want to > go back. > > For EFI the answer is more complicated. boot1.efi is going away, so > loader.efi will move to the ESP in \efi\freebsd\loader.efi, but it's easy > enough to have multiple versions there (loader_lua.efi and > loader_forth.efi) and select via EFI Shell or EFI Env variables which one > you want should you need to fall back. so, there are multiple loaders.   zfsloader and loader for example. how does this fit into the picture you are drawing? a symlink for each? > > Does that answer your concerns? > > Warner > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > From owner-freebsd-arch@freebsd.org Wed Feb 7 16:24:19 2018 Return-Path: Delivered-To: freebsd-arch@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 B842DF12798 for ; Wed, 7 Feb 2018 16:24:19 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 42A2970CE2 for ; Wed, 7 Feb 2018 16:24:19 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [10.1.38.238] (mobile-107-107-63-237.mycingular.net [107.107.63.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 8776E283C; Wed, 7 Feb 2018 16:24:12 +0000 (UTC) Date: Wed, 07 Feb 2018 11:24:10 -0500 User-Agent: K-9 Mail for Android In-Reply-To: References: <2c882f57-def0-b9f1-3c62-147cbe6bec02@metricspace.net> MIME-Version: 1.0 Subject: Re: Feedback on proposed loader changes To: Warner Losh CC: "freebsd-arch@freebsd.org" From: Eric McCorkle Message-ID: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:24:20 -0000 The issues tsoome raised with efipart have been dealt with in more recent u= pdates=2E He just hasn't been able to respond yet=2E On February 7, 2018 10:54:05 AM EST, Warner Losh wrote: >I'm afraid not=2E There's still unresolved issues in the efipart driver >changes in the reviews that tsoome raised, so it isn't ready=2E Lua is 3 >commits away and is to the point where all the refinement of those >three >changes is in code that's not in the tree yet=2E It goes in first, >hopefully >this week=2E I doubt there will be any affect on your ongoing work=2E > >Warner > >On Wed, Feb 7, 2018 at 5:41 AM, Eric McCorkle >wrote: > >> Might I suggest we integrate the GELI work before this goes in? It >can >> be added to loader as-is, and it works fine if you apply my >standalone >> loader patch (I have it deployed on a personal laptop)=2E >> >> I'm on the third major revision of this work (with countless smaller >> rebases), and I'd like to not have to redo it a fourth time=2E >> >> Basically, you'd need to commit some fixes to the efipart driver, the >> UEFI KMS driver, the keybuf integration, and finally, the GELI driver >> itself=2E I doubt this would interfere with 4th replacement, but I'd >like >> to not have this stuff get hit by stray changes=2E >> >> On 02/01/2018 00:03, Warner Losh wrote: >> > Greetings, >> > >> > As you may have read or guessed, I'm nearing the end game on >integrating >> > lua into the boot loader from the GSoC a few years ago=2E I've tried >to >> > resolve all the issues it brought up in libsa and other structural >> changes=2E >> > This has allowed lua to be imported unmodified, for example=2E >> > >> > I've been trying to figure out how to handle the transition from >forth to >> > lua and find myself with a few decisions that I should seek >feedback on >> > since I'm at a crossroads=2E >> > >> > The first one is that we have two sets of 4th words, both of which >I >> wrote, >> > that don't fit neatly into the current build system=2E We have a bit >of a >> > hack in place for both the pcibios-* and efi-* functions in 4th=2E >The >> former >> > was something I did as a hack for Netflix that I judged at the time >to be >> > more useful than it turned out to be (as far as I've been able to >tell)=2E >> > The latter turns out to be a road not taken (I'd planned originally >on >> > implementing UEFI boot manager with 4th, but that turns out to be >not >> > desirable even if 4th might be out the door)=2E My plan is to simply >retire >> > this stuff, along with pnp=2E4th which we've never installed=2E If I >do >> this, >> > then I can build everything in the tree w/o regard to whether FORTH >is on >> > or off, which dove tails nicely to my next question=2E=2E=2E >> > >> > If no =2Eo depends on the interpreter we're using (other than the >ones that >> > implement the interpreter), then there'd be no technical barrier to >> > building multiple interpreters=2E So, I'd like to change to building >both >> > the loader with forth and the one without, as well as installing >both (as >> > loader_simple and loader_forth) with a symlink to the default=2E This >would >> > allow people to switch, as well as provide a fallback for most >systems >> > (uboot on FAT would be trickier, but we don't directly install >those from >> > installworld, EFI on FAT would be as well, but there it will matter >much >> > less shortly)=2E This would allow me to roll out loader_lua when it's >ready >> > and have it installed everywhere for people that want to take the >plunge >> > and switch it when the time is ripe=2E This path would also leave the >old >> > boot loaders around for people to interrupt boot1 with (EFI is >another >> > matter, but I'm hoping efibootmgr wills solve that ball of wax)=2E >> > >> > So I'd like feedback on two questions: Should I kill the forth >features I >> > oulined above? And should I make the build system build multiple >loaders >> > with a link controlling the default? >> > >> > Comments? >> > >> > Warner >> > _______________________________________________ >> > freebsd-arch@freebsd=2Eorg mailing list >> > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-arch >> > To unsubscribe, send any mail to >"freebsd-arch-unsubscribe@freebsd=2Eorg" >> > >> _______________________________________________ >> freebsd-arch@freebsd=2Eorg mailing list >> https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to >"freebsd-arch-unsubscribe@freebsd=2Eorg" >> --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From owner-freebsd-arch@freebsd.org Wed Feb 7 16:31:04 2018 Return-Path: Delivered-To: freebsd-arch@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 CBDF7F12E4A for ; Wed, 7 Feb 2018 16:31:04 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F48E710CF for ; Wed, 7 Feb 2018 16:31:04 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (220-253-149-130.dyn.iinet.net.au [220.253.149.130]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w17GUxFg070406 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 7 Feb 2018 08:31:02 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Feedback on proposed loader changes To: Warner Losh , Eric McCorkle Cc: "freebsd-arch@freebsd.org" References: <2c882f57-def0-b9f1-3c62-147cbe6bec02@metricspace.net> From: Julian Elischer Message-ID: <3ef628a0-becd-dc4c-c3d0-efd121e841da@freebsd.org> Date: Thu, 8 Feb 2018 00:30:53 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:31:05 -0000 On 8/2/18 12:04 am, Warner Losh wrote: > > As for redoing things, I've just finished redoing ~15-years of sys/boot > neglect for stuff that wasn't done right the first time, so please be > patient with my pickiness. > > Warner the boot code in all its varying forms needs a full (re) writeup. the boot(8) man page and the handbook description (chapter 12 I think) are nowhere near complete. If you are doing this work I'd ask if you can spend a few hours on that too? That way we can follow what the new code is doing better. (and don't forget examples) Especially concentrating on changes.. From owner-freebsd-arch@freebsd.org Wed Feb 7 16:36:14 2018 Return-Path: Delivered-To: freebsd-arch@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 EF093F13506 for ; Wed, 7 Feb 2018 16:36:13 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 9170A7193F; Wed, 7 Feb 2018 16:36:13 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [10.1.38.238] (mobile-107-107-63-237.mycingular.net [107.107.63.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 302F72855; Wed, 7 Feb 2018 16:36:11 +0000 (UTC) Date: Wed, 07 Feb 2018 11:36:10 -0500 User-Agent: K-9 Mail for Android In-Reply-To: <3ef628a0-becd-dc4c-c3d0-efd121e841da@freebsd.org> References: <2c882f57-def0-b9f1-3c62-147cbe6bec02@metricspace.net> <3ef628a0-becd-dc4c-c3d0-efd121e841da@freebsd.org> MIME-Version: 1.0 Subject: Re: Feedback on proposed loader changes To: Julian Elischer ,Warner Losh CC: "freebsd-arch@freebsd.org" From: Eric McCorkle Message-ID: <7DD29EFF-2D94-4E14-9960-4BC47E5D922D@metricspace.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:36:14 -0000 The keybuf system also needs a man page (that's on me as it was my inventio= n)=2E On February 7, 2018 11:30:53 AM EST, Julian Elischer wrote: >On 8/2/18 12:04 am, Warner Losh wrote: >> >> As for redoing things, I've just finished redoing ~15-years of >sys/boot >> neglect for stuff that wasn't done right the first time, so please be >> patient with my pickiness=2E >> >> Warner >the boot code in all its varying forms needs a full (re) writeup=2E >the boot(8) man page and the handbook description (chapter 12 I think) >are nowhere near complete=2E >If you are doing this work I'd ask if you can spend a few hours on=20 >that too? >That way we can follow what the new code is doing better=2E >(and don't forget examples) >Especially concentrating on changes=2E=2E --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From owner-freebsd-arch@freebsd.org Wed Feb 7 16:40:03 2018 Return-Path: Delivered-To: freebsd-arch@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 609ADF138CB for ; Wed, 7 Feb 2018 16:40:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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)) by mx1.freebsd.org (Postfix) with ESMTPS id E4BD671B0E for ; Wed, 7 Feb 2018 16:40:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id n206so2955365itg.1 for ; Wed, 07 Feb 2018 08:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jZBCaCCdAohYx7cLjhQRglby6O2K+HEvw/Tfg46KWCU=; b=DCWvg41zIr0QekcOG0iQiGjdCCNFgZsgwLLfVHNjyboeAzikuisUEMksBacc2auTiC 13qkBId3VhKjR/9U6Zao9THJydMNtGNNEMFcbJsJpB1y1Zo1y7t4st6Pm7DCE4cjF3k/ j96HG2INNrAVy1oq2WGnJt7A9ab4CVDqR7N7wHoZVfA/Mm1tprBWzOAwkJq+isTtF3Nv OKUB4DuDI9AQVFPCfWrUjV37jrfgyUgil2Rxhci5fTDd/j5Y/1O4j6s0FYjiVH4jeAzV Wmf/845wlQ3UhmkzBmTvwxYalEsnnCAwN9sjrO1EJ/qBXqSVS3ttpK2usgMwtCJGXLTU ajCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jZBCaCCdAohYx7cLjhQRglby6O2K+HEvw/Tfg46KWCU=; b=l3H2YnbCM2Hk6qkbAFIIek8GpNL7++b/nIDmGWcjl5SLMllRz+7M9zCnPngFQ9Jcsl +E2RiD/7V35Hc0bv8KER9+1034nz70G+q7bqj7cYwmy4iMso14qMrw4FlhmYJzfKRqvJ j+Z2RqVSsUJHtBX+ZFGVm0PL1tI6U7ggTJzoff6nqGe7mLZL+4BPqLqUexjBzhhWtn6E 8br3HAQUInj75Obo3SKLzkX6cTYVfJaVuEr9JZpIyulOwBtGzU6+9DoNeb3B3lBxYf7y 3hoDmjOdvTyb5ydRj3n5YmtOC08+ur+9KdeptjgVSNozPMeLZXf31KsFNRx+00m8uwB3 ezzQ== X-Gm-Message-State: APf1xPD9qMbrAx5xaOSlaqRlQ3KLLTol/boI3Ir8RIvjNOnwnshOcClf vLsg6FOql8ACk1nATB5D/5f4t5XjwgGTSDIm86JWhQ== X-Google-Smtp-Source: AH8x225gmRZcOYUjk2c+IkFmtEGuSeYTd1/e8OKC29FZEs+azjq8rG7Ee/24vAIbo+4x3iwNd+I9gnEeardBTzmljDk= X-Received: by 10.36.146.196 with SMTP id l187mr9171215itd.115.1518021602219; Wed, 07 Feb 2018 08:40:02 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Wed, 7 Feb 2018 08:40:01 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <2f744512-6ed1-eebf-7dba-ddba2786d4de@freebsd.org> References: <5015.1517478674@critter.freebsd.dk> <2f744512-6ed1-eebf-7dba-ddba2786d4de@freebsd.org> From: Warner Losh Date: Wed, 7 Feb 2018 09:40:01 -0700 X-Google-Sender-Auth: DLQF66UjvWlwUQECr192VYvldN0 Message-ID: Subject: Re: Feedback on proposed loader changes To: Julian Elischer Cc: Devin Teske , Poul-Henning Kamp , Devin Teske , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:40:03 -0000 On Wed, Feb 7, 2018 at 9:22 AM, Julian Elischer wrote: > On 2/2/18 1:59 am, Warner Losh wrote: > >> On Thu, Feb 1, 2018 at 9:58 AM, Devin Teske wrote: >> >> >>> On Feb 1, 2018, at 1:51 AM, Poul-Henning Kamp >>>> >>> wrote: >>> >>>> -------- >>>> In message >>> >>> n3ESiUw@mail.gmail.com>, Warner Losh writes: >>> >>>> So I'd like feedback on two questions: Should I kill the forth feature= s >>>>> >>>> I >>> >>>> oulined above? And should I make the build system build multiple loade= rs >>>>> with a link controlling the default? >>>>> >>>> I think you should just move forward and go for the end-stage >>>> without too many temporary bandaids. >>>> >>>> The loader is pretty decoupled from everything, so in case anybody >>>> needs any of these Forth cornercases, they can use 11.X loader with >>>> very little, if any, trouble. >>>> >>>> As a person that both reviewed the GSoC code you are working with >>> (in-depth; including a list of short-comings) and the most likely perso= n >>> to >>> bring it up-to-par after it is committed, I have 2 opinions: >>> >>> 1. Please allow both boot systems for a while so that the lua-based men= u >>> can be made as feature full as the Forth menu. Example: submenus were >>> added >>> in Forth long after the GSoC lua project had ended >>> >>> OK. The plan outlined does that. The lua code will be installed into >> /boot. >> But it will be .lua, so no conflicts with .4th. And we start from >> loader.lua not loader.rc. >> >> >> 2. Please don=E2=80=99t force us to run Lua until I can code the new fea= tures >>> >>> OK >> >> >> And as the principal author of the Forth menu since 9.0: >>> >>> 3. Please give me a way to run my code (at the very least until I can >>> bring the Lua up to snuff; and if I can=E2=80=99t just let me run Forth >>> in-perpetuity). >>> >>> Interrupting boot1 so I can drive the system in the pre-boot Execution >>> env >>> is very important to me. >>> >> >> For !EFI, this is relatively easy. boot1 you can type /boot/loader_forth >> instead of the default /boot/loader if the symlink changes and you want = to >> go back. >> >> For EFI the answer is more complicated. boot1.efi is going away, so >> loader.efi will move to the ESP in \efi\freebsd\loader.efi, but it's eas= y >> enough to have multiple versions there (loader_lua.efi and >> loader_forth.efi) and select via EFI Shell or EFI Env variables which on= e >> you want should you need to fall back. >> > so, there are multiple loaders. zfsloader and loader for example. > how does this fit into the picture you are drawing? a symlink for each? > That's my plan. Of course, we shouldn't have a separate zfsloader and loader, but due to other limitaitons we do. At least we don't have a zfsloader.efi. Warner From owner-freebsd-arch@freebsd.org Thu Feb 8 02:04:43 2018 Return-Path: Delivered-To: freebsd-arch@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 47E63EEEB54 for ; Thu, 8 Feb 2018 02:04:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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)) by mx1.freebsd.org (Postfix) with ESMTPS id D0C216BB4F; Thu, 8 Feb 2018 02:04:42 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id n7so4188470iob.0; Wed, 07 Feb 2018 18:04:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SNvQLhecW6zaWXS3pKb5FxTAQUpR1Kq1vuIAOl5vHGw=; b=nkUNVMORzSorh1ubjL3dOZXfVi5wXy8G2qb5EzoVLMWujDZeBPPIN72DtX5rmeSRrr I6qfbXmrIyTs2st0LgdjbxQvnGnJqiPCce1cIItfuCkkerdj6oczYLv99r0X5bdAAtOB XZbJ+P6r6eB85JqXeOu+jbNSUrH7sS3F3JSy8z3C0zGbSgSuqW2zCKcCIUaEPBWc2KOR Qm6xGRSmF61jbT8Iq0Mcm/hFIuGlIjPI8+zkg+xwhfQdP0QrWe9F4vAG1EvDbd8bJ4qJ qBLOrKgKhj5HTSMjSnB2XgTfxEaZKY2TyLkIaiIRFmKkwVKzIbaJ9hTZ5fVJwjfvdHir R1uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SNvQLhecW6zaWXS3pKb5FxTAQUpR1Kq1vuIAOl5vHGw=; b=F7KXzV/RkoO4l51mrzp9QwfpCnPFe7tIE6+9ccwNeVYddgwU4rdpcJO4a7MYvoNihl xrQSCQqABC66WgAp3RDZjIGPXJFRvX8TmqSXwN/CsFv/uAjjGWcV0bxuLAN5thSeqMaQ 448qrQZOS2gZW/jdaid2yA6mmVREx7S3CoOK00IOst+KtpfcrzU8hEFOMdN1a+8+HVQE bkWclWqhY3/OI8GwRFc5I3H9BOr8hquvjFdJTRj8dFk7kBr7aboR4ARUivQPuBsUi2Tn MBeHrypiaH91lxCEmuiYPlyQtaGbbWjlZ4Rjq1HWiYzUXgeMnjz3hBh3ePBU16DT6mJR 3law== X-Gm-Message-State: APf1xPBKdnFrI377ToJrsWUL5te4uVO2ksT8M0nmD9mdJBoc/gy8ck+T 1gFxgl4wPBDjNhw1fGSKCrjst2oLK0aOvwpexTs= X-Google-Smtp-Source: AH8x227dxUyswUx0mra7tI5yXOvIAe1Rjkxc9tengNPpT5dmzUz1kM2MMalgUllWUtchmxDkxA2BXgNK6FwRHef5SOw= X-Received: by 10.107.107.1 with SMTP id g1mr9973735ioc.63.1518055482316; Wed, 07 Feb 2018 18:04:42 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.147.9 with HTTP; Wed, 7 Feb 2018 18:04:21 -0800 (PST) In-Reply-To: References: <5015.1517478674@critter.freebsd.dk> From: Ed Maste Date: Wed, 7 Feb 2018 21:04:21 -0500 X-Google-Sender-Auth: zguWl9GInl9WM9nVj0u9bYjhPxI Message-ID: Subject: Re: Feedback on proposed loader changes To: Warner Losh , Devin Teske Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 02:04:43 -0000 On 1 February 2018 at 11:58, Devin Teske wrote: > > 1. Please allow both boot systems for a while so that the lua-based menu can be made as feature full as the Forth menu. Zak, my co-op student from last term did a bunch of this work; it's in the lua-bootloader branch of https://github.com/ZakSN/freebsd. The work term ended before Warner's rework was ready, but it should be relatively straightforward to rebase it and begin review / refinement. I agree we should support both variants for at least some time. From owner-freebsd-arch@freebsd.org Thu Feb 8 05:42:47 2018 Return-Path: Delivered-To: freebsd-arch@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 741CAF0513A for ; Thu, 8 Feb 2018 05:42:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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)) by mx1.freebsd.org (Postfix) with ESMTPS id 01322745AB for ; Thu, 8 Feb 2018 05:42:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id k131so5219941ith.4 for ; Wed, 07 Feb 2018 21:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DvEETkNqT5dIO2OuP1Y8DSCiFeALpCAUiO+PsI2uqJA=; b=G551OmwLQlB0vsZl5XF+nhcsTqxsUT8XJrln26h2Z7E/vWVqbKTgpoHU9yOdKDFpp0 +2Ap2sl2DXK2W5F0LFY8VpS04g7tgD3rp6V1ZzNkzMBcfYYQZNGh0eGOElHdRO92lpmA B9ZPxZRK4+v0fITPhTxmOLPRdHBc8w699CuLWTf97hLGEb6bniU+XBuPHpcjntfMZfAt yNiR9kCZymwftwBhvi68CnIoT9RdBmlu7gsZPnBks2+9SCyqKV2+f1ToYGbJ09Q9hEIy ZBsOIv44m4yNh8Yu6qb/mHKMRF22tXKnw2kl79jocdrRQ3oyHu0en9TVsIZj1pzO4PUI kUaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DvEETkNqT5dIO2OuP1Y8DSCiFeALpCAUiO+PsI2uqJA=; b=sLW2CRn4ogZKbwZSvov0oXcb3OxLSgLXLLspleDHUUfPPlZl+w5CiDyUheBb3gaMYp ZL3rJyVdosybk5tO1QoZZ9KFZh4zJxSOHfMh3yTRViUHaE5kgA+rxG2JT0gR8sVThdCd 5EXPHwCl26ICytwBdHUT8VCsV+i9NfQKOzfq/qW9mxAOTKeri6Bcpmw/UUYcQ/mde6H0 JCgO0ctu3tS8DC/rJsjFwI4RXMA4sPf0m8n1/aNboa8MP35iKnX2lJzqr+vA98nVhW+n ySNR3UTaIWADT/ToHOeEObF95klCQSFSk4bWAUgi+OWSq6TlUBRWyU7VWYNJf3sjloxE dn6g== X-Gm-Message-State: APf1xPD0GfrO8xxLSSzNHqMLyT8NU6P1BMbT7KTzeVw05+ItYt4cBFEm KDNrXfTDGUx33qL8dpZExJ1Zm+dflEe/Ge/5/s+lkQ== X-Google-Smtp-Source: AH8x2270Si+k+fCCmzixW9KWPMrHybRd6owUaw/RTb+ZnJIvi4ZpFQcuzUJ+4hYlmiDi7cd8gJzElEPcv5U3tuNW0+k= X-Received: by 10.36.145.139 with SMTP id i133mr4564447ite.69.1518068566097; Wed, 07 Feb 2018 21:42:46 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Wed, 7 Feb 2018 21:42:45 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: References: <5015.1517478674@critter.freebsd.dk> From: Warner Losh Date: Wed, 7 Feb 2018 22:42:45 -0700 X-Google-Sender-Auth: KYsihNjpNzf-RX81UVzBmGyiWWE Message-ID: Subject: Re: Feedback on proposed loader changes To: Ed Maste Cc: Devin Teske , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 05:42:47 -0000 On Wed, Feb 7, 2018 at 7:04 PM, Ed Maste wrote: > On 1 February 2018 at 11:58, Devin Teske wrote: > > > > 1. Please allow both boot systems for a while so that the lua-based menu > can be made as feature full as the Forth menu. > > Zak, my co-op student from last term did a bunch of this work; it's in > the lua-bootloader branch of https://github.com/ZakSN/freebsd. The > work term ended before Warner's rework was ready, but it should be > relatively straightforward to rebase it and begin review / refinement. > I haven't changed the .lua code at all yet from what was in the github branch that Rui did to forward port the GSoC svn branch. I have plans for a lot of changes (since it's lame to call perform to call setenv when we can just directly do a setenv function call, for example). This code looks to be mergeable, so I'll do that as a separate commit. The non-lua bits I have to pick and choose, since there's some conflicts though... > I agree we should support both variants for at least some time. > Forth will be in 12, but not 13 is my plan. Lua will be in 12 and the default. And thanks to Kyle Evans' heroic MFCs, there's a fighting chance lua will be an off-by-default option in 11.2. Warner From owner-freebsd-arch@freebsd.org Thu Feb 8 08:57:42 2018 Return-Path: Delivered-To: freebsd-arch@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 5136BF105AE for ; Thu, 8 Feb 2018 08:57:42 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F00C17BBB1; Thu, 8 Feb 2018 08:57:41 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id E7BD9485B; Thu, 8 Feb 2018 08:57:41 +0000 (UTC) Received: by ivaldir.etoilebsd.net (Postfix, from userid 1001) id B23D16BC0E; Thu, 8 Feb 2018 09:57:41 +0100 (CET) Date: Thu, 8 Feb 2018 09:57:41 +0100 From: Baptiste Daroussin To: Warner Losh Cc: Ed Maste , Devin Teske , "freebsd-arch@freebsd.org" Subject: Re: Feedback on proposed loader changes Message-ID: <20180208085741.uhg4bxxobohem4kr@ivaldir.net> References: <5015.1517478674@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k2xo5ov6ky5hsv4z" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 08:57:42 -0000 --k2xo5ov6ky5hsv4z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 07, 2018 at 10:42:45PM -0700, Warner Losh wrote: > On Wed, Feb 7, 2018 at 7:04 PM, Ed Maste wrote: >=20 > > On 1 February 2018 at 11:58, Devin Teske wrote: > > > > > > 1. Please allow both boot systems for a while so that the lua-based m= enu > > can be made as feature full as the Forth menu. > > > > Zak, my co-op student from last term did a bunch of this work; it's in > > the lua-bootloader branch of https://github.com/ZakSN/freebsd. The > > work term ended before Warner's rework was ready, but it should be > > relatively straightforward to rebase it and begin review / refinement. > > >=20 > I haven't changed the .lua code at all yet from what was in the github > branch that Rui did to forward port the GSoC svn branch. I have plans for= a > lot of changes (since it's lame to call perform to call setenv when we can > just directly do a setenv function call, for example). >=20 > This code looks to be mergeable, so I'll do that as a separate commit. The > non-lua bits I have to pick and choose, since there's some conflicts > though... >=20 >=20 > > I agree we should support both variants for at least some time. > > >=20 > Forth will be in 12, but not 13 is my plan. Lua will be in 12 and the > default. And thanks to Kyle Evans' heroic MFCs, there's a fighting chance > lua will be an off-by-default option in 11.2. >=20 I just want to say thank you to both of you!!! Can wait to be able to use l= ua there! Best regards, Bapt --k2xo5ov6ky5hsv4z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlp8EQMACgkQY4mL3PG3 PlpGxg/+PfOfFzBdznuv1k16FpkxXKE7RO+Khq46abYaB+a77WJgDvty2/T87qqy 9dYk/XAd3CYyCKw7mj4+9ZKw2PuWc3hpsVyddekL/Qo4tMYJndVoKg1nffxZ4k0p OkURaPnttjR0vLRuFWS4mRIIGqjpgbxTJpIaW0RrTXgPITnv4lEbPutDaXx4jDSx RMyh07ibUhYruyK0Xw1IuqqAWbt79p4qlxXF8LrHLiDLZVg2+8eaHeoltbPFw+JK QDCNldLKQ/uNXIKweah5u45853yi4Qp7hO8ILvaroJ0FKmnL+yN7oVLuCBEBgn4N TpR94VwU1pRu023/7zpYz+VliSRJsGeNadEiceLLL3AASI1shdAYzajmvYgpZH8Z HbIrCn5pgqZmrDXYqO5Y18moMtWFBofUaapLRpj3J9hBLutUFC/J1EnQCiewqz75 4IZuSTbKWoC0+3HsujU4YpA/b7E58h/KLasbgbJ5Rh92h+gINWDRKAEB+JGwmHSY aOUGBgffsdyXPo2fHRyj0TEk+o80XAcgw8tefWww+k0jqupfxxihDWryLcYmc5GJ ipyNWEhoyrIISnWmNpc8eVjdCk9vNTVvbiECGwNa7bcum/zIV8gqsf91gn6Me1py KWmXCA0l336Cya2cqji17mjatE4wLg/FmT2gcB02DWZrkS/dg0Q= =rTMC -----END PGP SIGNATURE----- --k2xo5ov6ky5hsv4z--