efi, like the various ${MACHINE} directories, should have a dependency on
the enabled interpreters.
The general rule here is that any top-level directory that has a program at
any depth within that includes loader.mk should add ${INTERP_DEPENDS} added
to its dependencies so that the appropriate ficl/lua bits are ready before
they begin.
Note that the only directories in-tree that require it but will not get it
in a more appropriate manner are i386 (on amd64), efi, and userboot. i386
and userboot are handled explicitly in Makefile.amd64 where they are added
to S.yes.
Reported-by: bcran
MFC-after: 3 days
Draw console on efi.
Add vbe framebuffer for BIOS loader (vbe off, vbe on, vbe list,
vbe set xxx).
autoload font (/boot/fonts) based on resolution and font size.
Add command loadfont (set font by file) and
variable screen.font (set font by size). Pass loaded font to kernel.
Export variables:
screen.height
screen.width
screen.depth
Add gfx primitives to draw the screen and put png image on the screen.
Rework menu draw to iterate list of consoles to enamble device specific
output.
Probably something else I forgot...
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27420
Previously having ficl/liblua in LIB32LIST with their respective option
turned OFF would be relatively harmless, as we wouldn't act on it unless we
were building the non-32 variant. As of ac5f382a9d, however, these are
now used for dependencies in some cases and must reflect what's actually
going to be built.
buildworld already runs the stand build in parallel[1], so make it easier to
identify ordering issues by properly establishing dependencies or adding
.WAIT where needed.
Everything in stand/ relies on libsa, either directly or indirectly, because
libsa build is where the stand headers get installed and it gets linked in
most places.
Interpreters depend on their libs, machine dirs usually depend on top-level
libs that are getting built and at least one of the interpreter flavors.
For i386, order btx/libi386/libfirewire before everything else using a
big-ol-.WAIT hammer. btx is the most common dependency, but the others are
used sporadically. This seems to be where the race reporting on the mailing
list is- AFAICT, the following sequence is happening:
1.) One of the loaders gets built based on stale btx/btxldr
2.) btx/btxldr gets rebuilt
3.) installworld triggers loader rebuild because btx was rebuilt after
This seems like the most plausible explanation, as they've verified system
time and timestamps.
While we're here, let's switch stand/ over to a completely parallel build so
we can work out these kinds of issues in isolation rather than in the middle
of a larger build.
Reviewed by: bdragon, sjg, tsoome
Tested by: bdragon (-j1024, no failures, significant speed improvement)
Differential Revision: https://reviews.freebsd.org/D23411
Since rS330365, there has been no particular reason for libofw to be in a
subdirectory of ofw. Move libofw up a level to make it fit in better with
the other top level libraries.
Also add a LIBOFWSRC to stand/defs.mk to match what all the other
libraries are doing.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D23000
Move the libzfs stuff into libsa. There's no need for it to be a
separate library. The separate library adds to the issues of build
ordering that we see from time to time. Move the filesystem support
into libsa, like all the other filesystem support rather than making
zfs the odd-duck out.
Discussed with: allanjude@
Reduce by 1 the number of crazy libraries we need in stand by moving
geli into libsa (where architecturally it belonged all along). This
just moves things around without any code changes.
Makefile.${MACHINE_ARCH} and remove the now-empty files. Generate the
*32 directories on the necessary architectures (well, currently only
amd64) on the fly. Remove LOADER_EFI variable and co-locate it with
EFI.
Differential Review: https://reviews.freebsd.org/D14546
We really only need one loader.conf. The other loader.conf was created
because the current one took forever to parse in FORTH. That will be
fixed in the next commit.
These are the .lua files from from Pedro Souza's 2014 Summer of Code
project. Rui Paulo, Pedro Arthur and Wojciech A. Koszek also
contributed.
Obtained from: https://wiki.freebsd.org/SummerOfCode2014/LuaLoader
Sponsored by: Google Summer of Code
Improve the SoC lua menu code to bring it in line with forth
menu functionality
Submitted by: Zakary Nafziger
Sponsored by: FreeBSD Foundation
Use loader.setenv and loader.unsetenv instead of loader.perform
Convert from include("/boot/foo.lua") to foo = require("foo");
to bring in line with latest lua module conventions.
Enforce a uniform style for the new .lua files:
o hard tab indenation for 8 spaces
o don't have if foo then bar; else bas; end on one line
MFC After: 1 month
Relnotes: yes
Differential Review: https://reviews.freebsd.org/D14295
liblua glues the lua run time into the boot loader. It implements all
the runtime routines that lua expects. In addition, it has a few
standard 'C' headers that nueter various aspects of the LUA build that
are too specific to lua to be in libsa. Many refinements from the
original code to improve implementation and the number of included lua
libraries. Use int64_t for lua_Number. Have "/boot/lua" be the default
module path. Numerous cleanups from the original GSoC project,
including hacking libsa to allow lua to be built with only one change
outside luaconf.h.
Add the final bit of lua glue to bring in liblua and plug into the
multiple interpreter framework, previously committed.
Add LOADER_LUA option, currently off by default.
Presently, this is an experimental option. One must opt-in to using
this by defining WITH_LOADER_LUA and WITHOUT_FORTH. It's been
lightly tested, so keep a backup copy of your old loader handy.
The menu code, coming in the next commit, hasn't been exhaustively
tested. A LUA boot loader is 60k larger than a FORTH one, which is
80k larger than a no-interpreter one. Subtle changes in size
may tip things past some subtle limit (the binary is ~430k now
when built with LUA). A future version may offer coexistance.
Bump FreeBSD version to 1200058 to mark the milestone.
Pedro Souza's 2014 Summer of Code project. Rui Paulo, Pedro Arthur,
Zakary Nafziger and Wojciech A. Koszek also contributed. Warner Losh
reworked it extensively into its current form.
Obtained from: https://wiki.freebsd.org/SummerOfCode2014/LuaLoader
Sponsored by: Google Summer of Code
Relnotes: Yes
MFC After: 1 month
Differential Review: https://reviews.freebsd.org/D14295
