On 17/10/16 18:40, John Baldwin wrote:
I'm a bit hesitant to do all the type parsing in the kernel vs userland.
However, I think having smbios(4) export a /dev/smbios that you can either
read() or mmap() to access the table would be very convenient and let you
keep the bits to parse the table in userland (and not require root if we
allow read-only access to mortals on /dev/foo).
This is probably a bit left-field, but I'm wondering if both methods
(expose-to-loader-kenv and user-space-accessible devfs node) can be
re-used for things like the Linux-oriented kernel environment page
exported by SYSLINUX/PXELINUX memdisk, which I've used with some success
to boot FreeBSD installers in heterogeneous private cloud/lab setups.
It exports this information using an ACPI-like table in that BIOS HBA
type area in x86 address space, but the table is not DSDT linked (it's
not produced by the BIOS).
Having a coherent means of dealing with it would be very useful, as such
FreeBSD installers (which I've deployed as mfsBSD images) can then
basically re-use what's been done for EFI variables for those legacy
systems which don't support/can't use EFI network boot. As yet, I've not
tried this with 64-bit EFI systems.
email@example.com mailing list
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"