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