Date: Wed, 7 Feb 2018 09:04:12 -0700 From: Warner Losh <imp@bsdimp.com> To: Eric McCorkle <eric@metricspace.net> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Feedback on proposed loader changes Message-ID: <CANCZdfoCJhLEf5fcenWJ3No=Pm-QaynubWjxzBEk4gXkRmOsaQ@mail.gmail.com> In-Reply-To: <CANCZdfo4PB6mUFQ-%2B09xLZnBBxKH0LFCrTjVE=jD6oeFTodaZw@mail.gmail.com> References: <CANCZdfoF4M1k=wOzueg0KQk9tRoQT-hO0SrB51wxv=-n3ESiUw@mail.gmail.com> <2c882f57-def0-b9f1-3c62-147cbe6bec02@metricspace.net> <CANCZdfo4PB6mUFQ-%2B09xLZnBBxKH0LFCrTjVE=jD6oeFTodaZw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <imp@bsdimp.com> 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 <eric@metricspace.net> > 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" >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoCJhLEf5fcenWJ3No=Pm-QaynubWjxzBEk4gXkRmOsaQ>