> From: <owner-src-committ...@freebsd.org> on behalf of Doug Ambrisko
> Date: 2016-10-14, Friday at 10:27
> To: Warner Losh <i...@bsdimp.com>
> Cc: Doug Ambrisko <ambri...@freebsd.org>, src-committers
> <src-committ...@freebsd.org>, "svn-src-...@freebsd.org"
> <svn-src-...@freebsd.org>, "firstname.lastname@example.org"
> Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader
> On Fri, Oct 14, 2016 at 11:16:02AM -0600, Warner Losh wrote:
> | Love the functionality, but don't like using the 'hint' namespace for
> | this. Can we change it now before too many things depend on it? We had
> | similar issues in ACPI and moved it to the 'acpi' space. Can we move
> | this to the 'smbios' space please?
> | The reason is that 'hint' is special and sometimes filtered out, so it
> | is a poor choice to export data from the boot loader to the kernel.
> The reason I picked hint was it could be put /boot/device.hints
> to make it work as well and that it was a hint. Other standards in the
> future might use other methods. Looking back over the email I had
> with John he had suggested hint.smbios.0.anchor to make this look
> different. This code had been hanging around for so long I forgot
> about that and we were using hint.smbios.0.mem in our shipping code base.
> However, I hope that nothing would use this except for smbios(4) and
> for people to make smbios(4) useful for this info.
Doug's looking at me when he says that. :-)
We talked about this last night at BAFUG; right now, even if smbios(4) is able
to find the SMBIOS info -- it currently only looks at the aforementioned
0xf0000 - 0xfffff range, so it can't find it on UEFI -- smbios(4) doesn't
actually provide any interface for that information. Doug and I have talked
about making smbios(4) useful, by parsing the data and providing KPIs and APIs,
for years now; I think I'll *finally* have the time and motivation to do so
> Doug A.
email@example.com mailing list
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"