On 17/10/16 21:23, Bruce Simpson wrote:
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
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.

PS Hit send too soon -- the main reason a FreeBSD installer, or image wrapper for a FreeBSD installer tool (akin to the Debian style of network driven installer), would need access to the memdisk's ACPI-style table (containing boot & textual 'environment' page, filled out by the TFTP boot server, perhaps by scripted means) is...

...where it can't intuit all system configuration settings by reference to its primary MAC address alone, or where it needs network bootstrap information to proceed with other provisioning methods (straight to Puppet/Ansible, and/or fetching a list of pkgng pkgs to grab from some trusted package server).

The code required would just pretty much resemble what you guys are doing for EFI right now, but for BIOS-era systems (of which we've got a large installed base, and mass provisioning those would be great, for the sake of recycling.)
svn-src-head@freebsd.org mailing list
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to