On Thu, 2016-04-14 at 10:43 -0600, Warner Losh wrote: > On Thu, Apr 14, 2016 at 2:22 AM, Andrew Turner <and...@fubar.geek.nz> > wrote: > > > On Thu, 14 Apr 2016 04:59:51 +0000 (UTC) > > Warner Losh <i...@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. -- 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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
