svn commit: r307326 - head/sys/boot/efi/loader

[Bruce Simpson]

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