Date: Thu, 14 Apr 2016 11:00:06 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: Andrew Turner <andrew@fubar.geek.nz>, Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r297954 - in head/sys: boot/efi/loader/arch/amd64 boot/i386/libi386 x86/acpica Message-ID: <CANCZdfrCHBu=GG5=-GcOyjcOQDt%2Bxp6nu5WW7%2B8FXSfmu_j8FA@mail.gmail.com> In-Reply-To: <1460652564.52955.28.camel@freebsd.org> References: <201604140459.u3E4xpYv038183@repo.freebsd.org> <20160414092229.1ba8d6c5@zapp> <CANCZdfoOGEPag5wk=85K4UZRjeuM9oTr=FMbLzp-hR8ZL8T33g@mail.gmail.com> <1460652564.52955.28.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 14, 2016 at 10:49 AM, Ian Lepore <ian@freebsd.org> wrote: > On Thu, 2016-04-14 at 10:43 -0600, Warner Losh wrote: > > On Thu, Apr 14, 2016 at 2:22 AM, Andrew Turner <andrew@fubar.geek.nz> > > wrote: > > > > > On Thu, 14 Apr 2016 04:59:51 +0000 (UTC) > > > Warner Losh <imp@FreeBSD.org> wrote: > > > > > > > Author: imp > > > > Date: Thu Apr 14 04:59:51 2016 > > > > New Revision: 297954 > > > > URL: https://svnweb.freebsd.org/changeset/base/297954 > > > > > > > > Log: > > > > Deprecate using hints.acpi.0.rsdp to communicate the RSDP to > > > > the > > > > system. This uses the hints mechnanism. This mostly works today > > > > because when there's no static hints (the default), this value > > > > can > > > > be fetched from the hint. When there is a static hints file, the > > > > hint > > > > passed from the boot loader to the kernel is ignored, but for > > > > the > > > > BIOS case we're able to find it anyway. However, with UEFI, the > > > > fallback doesn't work, so we get a panic instead. > > > > > > > > Switch to acpi.rsdp and use TUNABLE_ULONG_FETCH instead. > > > > Continue to > > > > generate the old values to allow for transitions. In addition, > > > > fall > > > > back to the old method if the new method isn't present. > > > > > > > > Add comments about all this. > > > > > > > > Differential Revision: https://reviews.freebsd.org/D5866 > > > > > > Why not pass it in using module data as we do with the DTB? It > > > would > > > fix issues where we have either or both static hints and a stat > > > env. > > > > > > > I viewed that as brittle. And it was longer to code. This works with > > static > > hints, but not static env. Static env tends not to be used on x86. > > > > I'm open to putting it into module data as a more robust solution. I > > just > > didn't have the extra time it would take to do so at the moment. > > > > Another thing that I think should be passed the way we pass loaded > modules is GELI password and/or key data. It's currently passed in the > environment, and static env subverts that. While static env has mostly > been an embedded-system thing to date, there is more x86 embedded > hardware hitting the market these days. > > Maybe we need some helper code to make it easy to encapsulate data in a > module-like form on the loader side, and access it from the kernel > side, to make it easier to pass binary data from the loader without > having to ascii-encode it into the environment. I'd support exporting it to the kernel via module data. That's more secure anyway, and can be expanded to other bits of data that need to be communicated between the bootloader and kernel that one may not wish to otherwise disclose. It certainly would clear up one ugly wart on the kernel environment and make further cleanups possible and a sane undertaking. Warner > > -- Ian > > > > > > Whatever method is decided we will also need it on arm64 as we > > > claim to > > > support ACPI there, although no backwards compatibility will be > > > needed > > > as the code is most likely broken as it's only partially been > > > tested. > > > > > > > Yes. The issue is with ACPI + UEFI. With ACPI + BIOS, we could find > > things always, and this didn't matter. This change doesn't change > > that. > > But for UEFI, the RSDP table can be (and often is) located in areas > > the code doesn't search. > > > > We likely need to unify more than just passing in the RSDP, since if > > we want > > to callout to UEFI after the kernel has booted, there's a number of > > other > > things that need to be passed as well. I have a review that gets this > > working > > on x86 that I'll open up when more of my backlog has been pushed into > > the tree. I'll be sure to include you. > > > > Warner >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrCHBu=GG5=-GcOyjcOQDt%2Bxp6nu5WW7%2B8FXSfmu_j8FA>