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
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.
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-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"
