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" >