Change Details

1. Create is_ascii to see if we have an ASCII string Abstract out the printability test from the env printing routine. It's useful elsewhere. Keep the NUL test inside the printing routine, however, since this routine is maxmially useful if it doesn't assume NUL termination. 2. Read in and parse /efi/freebsd/loader.env from the boot device's partition as if it were on the command line. This lets one set environment variables in the bootloader. Unfortunately, we don't have all the mechanisms in place to parse the file, nor do we have the magic pattern matching in place that loader.conf has. Variables are of the form foo=bar. No quotes are supported, so spaces aren't allowed, for example. Also, variables like foo_load=yes are intercepted when we parse the loader.conf file and things are done based on that. Since those aren't done here, variables that cause an action to happen won't work. 3. Implement rootdev_uefi If rootdev_uefi is set in the environment, then treat it like a device path. Convert the string to a device path and see if we can find a device that matches. If so, use that device at our root dev no matter what. If it's bad in any way, the boot will fail. 4. Implement uefi_ignore_boot_mgr env variable. When set, we ignore all the hints that the UEFI boot manager has set for us. We also always fail back to the OK prompt when we can't find the right thing to boot rather than failing back to the UEFI boot manager. This has the side effect of also expanding the cases where we fail back to the OK prompt to include when we're booted under UEFI, but UEFI::BootCurrent isn't set in the environment and we can't find a proper place to boot from. 5. Provide bridge between UEFI variables and FreeBSD Boot Loader variables. Just after we set the fallback console to efi, loop through all the UEFI variables. All with GUID of d2bf216b-bcc0-402c-b0ed-fe62cdccd332b are considered further. If the variable name (key) and the variable value (val) are printable ascii characters, do setenv(key, val, 1). On BIOSes that support it, this allows an easy way to set loader env vars to override things that might otherwise be difficult to override.

1. Add efi_freebsd_delenv Add a wrapper around efi_delenv akin to efi_freebsd_getenv and efi_getenv. 2. Read in and parse /efi/freebsd/loader.env from the boot device's partition as if it were on the command line. Fetch FreeBSD-LoaderEnv UEFI enviornment variable. If set, read in loader environment variables from it. Otherwise read in /efi/freebsd/loader.env. Both are read relative to the device loader.efi loaded from (they aren't full UEFI device paths) Next fetch FreeBSD-NextLoaderEnv UEFI environment variable. If present, read the file it points to in as above and delete the UEFI environment variable so it only happens once. This lets one set environment variables in the bootloader. Unfortunately, we don't have all the mechanisms in place to parse the file, nor do we have the magic pattern matching in place that loader.conf has. Variables are of the form foo=bar. No quotes are supported, so spaces aren't allowed, for example. Also, variables like foo_load=yes are intercepted when we parse the loader.conf file and things are done based on that. Since those aren't done here, variables that cause an action to happen won't work. 3. Implement rootdev_uefi If rootdev_uefi is set in the environment, then treat it like a device path. Convert the string to a device path and see if we can find a device that matches. If so, use that device at our root dev no matter what. If it's bad in any way, the boot will fail. 4. Implement uefi_ignore_boot_mgr env variable. When set, we ignore all the hints that the UEFI boot manager has set for us. We also always fail back to the OK prompt when we can't find the right thing to boot rather than failing back to the UEFI boot manager. This has the side effect of also expanding the cases where we fail back to the OK prompt to include when we're booted under UEFI, but UEFI::BootCurrent isn't set in the environment and we can't find a proper place to boot from. NOTE: I removed the iteration through the environment GUID space since I don't need it initially for stuff I'm doing and I'm unsure of its actual value.

1. Create is_ascii to see if we have an ASCII string Add efi_freebsd_delenv Abstract out the printability test from the env printing routine. It's useful elsewhere. Keep the NUL test inside the printing routine, however, since this routine is maxmially useful if it doesn't assume NUL terminationdd a wrapper around efi_delenv akin to efi_freebsd_getenv and efi_getenv. 2. Read in and parse /efi/freebsd/loader.env from the boot device's partition as if it were on the command line. This lets one set environment variables in the bootloader. Unfortunately, we don't have all the mechanisms in place to parse the file, nor do we have the magic pattern matching in place that loader.conf has. Variables are of the form foo=bar. No quotes are supported, so spaces aren't allowed,Fetch FreeBSD-LoaderEnv UEFI enviornment variable. for example.If set, Also,read in loader environment variables from it. variables like foo_load=yes are intercepted when we parse the loader.conf file and things are done based on that. Since those aren't done here,Otherwise read in /efi/freebsd/loader.env. variables that cause an action to happen won't work.Both are read relative to the device loader.efi loaded from (they aren't full UEFI device paths) Next fetch FreeBSD-NextLoaderEnv UEFI environment variable. If present, read the file it points to in as above and delete the UEFI environment variable so it only happens once. This lets one set environment variables in the bootloader. Unfortunately, we don't have all the mechanisms in place to parse the file, nor do we have the magic pattern matching in place that loader.conf has. Variables are of the form foo=bar. No quotes are supported, so spaces aren't allowed, for example. Also, variables like foo_load=yes are intercepted when we parse the loader.conf file and things are done based on that. Since those aren't done here, variables that cause an action to happen won't work. 3. Implement rootdev_uefi If rootdev_uefi is set in the environment, then treat it like a device path. Convert the string to a device path and see if we can find a a device that matches. If so, use that device at our root dev no matter what. If it's bad in any way, the boot will fail. 4. Implement uefi_ignore_boot_mgr env variable. When set, we ignore all the hints that the UEFI boot manager has set set for us. We also always fail back to the OK prompt when we can't find the right thing to boot rather than failing back to the UEFI boot manager. This has the side effect of also expanding the cases where we we fail back to the OK prompt to include when we're booted under UEFI, but UEFI::BootCurrent isn't set in the environment and we can't find a a proper place to boot from. 5. Provide bridge between UEFI variables and FreeBSD Boot Loader variables. Just after we set the fallback console to efi, loop through all the UEFI variables. All with GUID of d2bf216b-bcc0-402c-b0ed-fe62cdccd332b are considered further. If the variable name (key) and the variable value (val) are printable ascii characters, do setenv(key, val, 1). On BIOSes that support it, this allows an easy way to set loader env vars to override things that might otherwise be difficult to overridNOTE: I removed the iteration through the environment GUID space since I don't need it initially for stuff I'm doing and I'm unsure of its actual value.