Date: Fri, 14 Oct 2016 11:43:46 -0700 From: Doug Ambrisko <ambrisko@ambrisko.com> To: Warner Losh <imp@bsdimp.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers <src-committers@freebsd.org>, Doug Ambrisko <ambrisko@freebsd.org>, Ravi Pokala <rpokala@mac.com> Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader Message-ID: <20161014184346.GA71804@ambrisko.com> In-Reply-To: <CANCZdfqV3rtEDxFLwfOJxs2prUfrXbh1N6G8KWy3VjXy6w7vwg@mail.gmail.com> References: <201610141710.u9EHArlL089412@repo.freebsd.org> <CANCZdfo0JE_BMWZOHerNVez2HG3PZ4Y=H8ZYZjbZdQVthD=z-w@mail.gmail.com> <20161014172705.GA65545@ambrisko.com> <3FF8A9D8-0C8A-4033-A7FC-8B64E9AB025F@panasas.com> <20161014175542.GB65545@ambrisko.com> <CANCZdfqV3rtEDxFLwfOJxs2prUfrXbh1N6G8KWy3VjXy6w7vwg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 14, 2016 at 12:25:54PM -0600, Warner Losh wrote:
| On Oct 14, 2016 11:55 AM, "Doug Ambrisko" <[1]ambrisko@ambrisko.com>
| wrote:
| >
| > On Fri, Oct 14, 2016 at 10:33:15AM -0700, Ravi Pokala wrote:
| > | -----Original Message-----
| > | > From: <[2]owner-src-committers@freebsd.org> on behalf of Doug
| Ambrisko <[3]ambrisko@ambrisko.com>
| > | > Date: 2016-10-14, Friday at 10:27
| > | > To: Warner Losh <[4]imp@bsdimp.com>
| > | > Cc: Doug Ambrisko <[5]ambrisko@freebsd.org>, src-committers
| <[6]src-committers@freebsd.org>, "[7]svn-src-all@freebsd.org"
| <[8]svn-src-all@freebsd.org>, "[9]svn-src-head@freebsd.org"
| <[10]svn-src-head@freebsd.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 "soon".
| >
| > I've actually talked to a few people. However, your the first to
| > step up. This needs to be designed and will take some time and
| > review. I would hope that except for smbios(4), nothing else would
| > use this kenv but there is nothing to prevent that :-( I could name
| > it super_secret_dont_use.
| >
| > BTW, to get you started this patch prevents smbios(4) from blowing
| chunks
| > when it gets a anchor in high memory and works on legacy machines.
| >
| > --- /sys/x86/bios/smbios.c 2013-10-01 14:28:25.000000000 -0700
| > +++ ./smbios.c 2016-04-11 11:58:03.234969000 -0700
| > @@ -38,6 +38,7 @@ __FBSDID("$FreeBSD: release/9.2.0/sys/x8
| > #include <machine/bus.h>
| > #include <machine/resource.h>
| > #include <sys/rman.h>
| > +#include <sys/sysctl.h>
| >
| > #include <vm/vm.h>
| > #include <vm/vm_param.h>
| > @@ -59,7 +60,7 @@ struct smbios_softc {
| > };
| >
| > #define RES2EPS(res) ((struct smbios_eps
| *)rman_get_virtual(res))
| > -#define ADDR2EPS(addr) ((struct smbios_eps
| *)BIOS_PADDRTOVADDR(addr))
| > +#define ADDR2EPS(addr) ((struct smbios_eps
| *)PHYS_TO_DMAP(addr))
| >
| > static devclass_t smbios_devclass;
| >
| > @@ -71,19 +72,26 @@ static int smbios_modevent (module_t, in
| >
| > static int smbios_cksum (struct smbios_eps *);
| >
| > +static unsigned long addr;
| > +static SYSCTL_NODE(_hw, OID_AUTO, smbios, CTLFLAG_RD, 0,
| > + "SMBIOS driver parameters");
| > +SYSCTL_LONG(_hw_smbios, OID_AUTO, mem, CTLFLAG_RW,
| > + &addr, 0, "");
| > +
| > static void
| > smbios_identify (driver_t *driver, device_t parent)
| > {
| > device_t child;
| > - u_int32_t addr;
| > int length;
| > int rid;
| >
| > if (!device_is_alive(parent))
| > return;
| >
| > - addr = bios_sigsearch(SMBIOS_START, SMBIOS_SIG, SMBIOS_LEN,
| > - SMBIOS_STEP, SMBIOS_OFF);
| > + if (resource_long_value("smbios", 0, "mem", &addr) != 0 ||
| > + addr == 0)
| > + addr = bios_sigsearch(SMBIOS_START, SMBIOS_SIG,
| SMBIOS_LEN,
| > + SMBIOS_STEP, SMBIOS_OFF);
| > if (addr != 0) {
| > rid = 0;
| > length = ADDR2EPS(addr)->length;
| >
| > Note I don't plan to commit this since it doesn't really do much and
| we
| > need a lot more.
|
| I was planning on exporting all smbios stuff via sysctl.
|
| You can still put non hints.* in device.hints too.
I wondered about that. It would look a bit strange.
| I can rework things a bit to be more complete is you like...
That would be great. A few people have expressed need of this from a
kernel level. Adrian mentioned it for NUMA, ipmi(4) needs it, it
could be used on Dell machines to fix HW layout issues for NICs.
A couple companies could use it for internal needs. Anything to
move this forward would help. I don't mind running dmidecode etc.
but not needing that would be nice.
Thanks,
Doug A.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161014184346.GA71804>