FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=stable%2F13 2023-08-23T17:43:33Z 2023-08-23T17:43:33Z Warner Losh imp@FreeBSD.org 2023-08-22T01:32:26Z urn:sha1:a7385d2a904a5e7d8cde296faf9f0b399f318cdb Remove /^--\n--\s*\$FreeBSD\$.*$\n/ Similar commit in main: (cherry picked from commit 9636a14538f5) 2023-07-25T15:13:49Z Warner Losh imp@FreeBSD.org 2023-05-10T15:40:58Z urn:sha1:caa41f641755c935b036e17440a3b49329c904ed The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix (cherry picked from commit 4d846d260e2b9a3d4d0a701462568268cbfe7a5b) 2020-03-27T17:37:31Z Ryan Moeller freqlabs@FreeBSD.org 2020-03-27T17:37:31Z urn:sha1:73531a2abd8de866a3581d556b026b278fdedffa Reviewed by: kevans Reviewed by: tsoome Approved by: mav (mentor) MFC after: 1 week Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D21733 2020-01-25T03:02:45Z Kyle Evans kevans@FreeBSD.org 2020-01-25T03:02:45Z urn:sha1:59ba5b1dc2742257c16060009e5e674ec12bc020 The major problem with the current ordering is that loader.conf may contain all of the magic we need to actually setup the console, so loading local.lua prior to that can make it excessively difficult and annoying to debug (whoops, sorry Ravi & Warner). The new ordering has some implications, but I suspect they are a non-issue. The first is that it's no longer possible for the local module to inject any logic prior to loading config -- I suspect no one has relied on this. The second implication is that the config.loaded hook is now useless, as the local module will always be included after that hook would have fired. For config.loaded, I will opt to leave it in, just in case we add an early point for local lua to get injected or in case one wants to schedule some deferred logic in a custom loader.lua. The overhead of having it if no hooks will be invoked is relatively minimal. Diagnosed by: imp Reported by: imp, rpokala (most likely) MFC after: 3 days 2018-08-30T13:29:32Z Kyle Evans kevans@FreeBSD.org 2018-08-30T13:29:32Z urn:sha1:ca703fe987439c78ab2bcc9d890281f6b2112c03 Resetting to the default color scheme was done prior to reading the config. This is bogus; colors may only be declined by the user with the loader.conf(5) variable "loader_color", so such a request for no color will not be completely honored as we reset to the default color scheme unconditionally. Approved by: re (rgrimes) 2018-06-12T03:44:34Z Kyle Evans kevans@FreeBSD.org 2018-06-12T03:44:34Z urn:sha1:5d2791646b0161659f2fc2e4e2909c996ca0ffdb To recap the problem: with a black-on-white xterm, the menu draws terribly. Ideally, we would try our best for a white-on-black context for the menu since graphics and whatnot might not be tested for other setups and there's no reasonable way to sample the terminal at this point for the used color scheme. This commit attempts to address that further in two ways: - Instead of issuing CSI bg/fg resets (CSI 39m and CSI 49m respectively for "default"), issue CSI bg/fg escape sequences for our expected color scheme - Reset to *our* default color scheme before we even attempt to load the local module, so that we personally don't have any earlier text with the console default color scheme. Reported by: emaste (again) 2018-04-06T15:19:48Z Kyle Evans kevans@FreeBSD.org 2018-04-06T15:19:48Z urn:sha1:814a016d28f66cac4a7cd371f38fb6eae72265c6 Earlier efforts to stop loading the menu broke the ability to skip the menu with, e.g., beastie_disable in loader.conf(5) as it was decided before configuration was read. Defer bringing in the menu module until we've loaded configuration so that we can make a more informed decision on whether the menu should be skipped or not. 2018-03-26T19:01:22Z Kyle Evans kevans@FreeBSD.org 2018-03-26T19:01:22Z urn:sha1:07faaf781556369bf1239dd727a3e0396b4d88a7 This provides a way to optionally include a module without having to wrap it in filesystem checks. try_include is a little more robust, using the lua search path instead of forcing us to explicitly consider all of the places we could want to include a module. Errors are still generally raised from trying to load the module, but ENOENT will not get raised unless we're doing a verbose load. This will also be used to split out logo/brand graphics into their own files so that we can safely scale up the number of graphics included without worrying about the extra memory consumption- opting to lazily load graphics instead. Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D14658 2018-03-21T20:36:57Z Kyle Evans kevans@FreeBSD.org 2018-03-21T20:36:57Z urn:sha1:5f8cfbe1348dac0abce73c344af2eab0ccaae732 boot1 is too early to be deciding a good resolution. Console modes don't map cleanly/predictably to actual screen resolutions, and GOP does not reflect the actual screen resolution after a console mode change. Rip it out. Add an efi-autoresizecons command to loader to choose an optimal screen resolution based on the current environment. We'll explicitly execute this later, preferably before we draw anything of value but after we load config and pick up any tunables we may need to decide where we're going. This method also allows us to actually pass the correct framebuffer information on to the kernel. UGA autoresizing is not implemented because it doesn't have the kind of mode enumeration that GOP does. If an interested person with relevant hardware could get in contact, we can take a look at implementing UGA autoresize. This effectively "fixes" the breakage caused by r327058, but doesn't actually set the resolution correctly until the interpreter calls efi-autoresizcons. The lualoader version of this has been included for reference; the forth equivalent will follow. Reviewed by: imp (with some hestitation), manu Differential Revision: https://reviews.freebsd.org/D14788 2018-03-19T15:48:31Z Kyle Evans kevans@FreeBSD.org 2018-03-19T15:48:31Z urn:sha1:85efc91a3c81b448a5d01bbd24faa17215568d35 The console may have been set for different colors before lualoader kicks in; notably, a black-on-white color scheme is not necessarily what we're expecting. While here, make color.default() a composition of color.escape() instead of rewriting the escape sequence to make it more obvious what it's achieving: a white-on-black color scheme with no attributes set. Reported by: emaste, whose eyes may rest easily