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.
_______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
