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
Introduce WITH_/WITHOUT_LLVM_COV to match GCC's WITH_/WITHOUT_GCOV.
It is intended to provide a superset of the interface and functionality
of gcov.
It is enabled by default when building Clang, similarly to gcov and GCC.
This change moves one file in libllvm to be compiled unconditionally.
Previously it was included only when WITH_CLANG_EXTRAS was set, but the
complexity of a new special case for (CLANG_EXTRAS | LLVM_COV) is not
worth avoiding a tiny increase in build time.
Reviewed by: dim, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D142645
of blocks used by a requested list of inodes.
For example, to list the blocks referenced by your kernel:
guest_12 % df /
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/gpt/rootfs 20307196 10707336 7975288 57% /
guest_12 % ls -i /boot/kernel/kernel
160603 /boot/kernel/kernel
guest_12 % ./prtblknos /dev/gpt/rootfs 160603
160603: lbn 0-7 blkno 3217584-3217647
lbn 8-11 blkno 3217864-3217895 distance 216
First-level indirect, blkno 3217896-3217903 distance 0
lbn 12-19 blkno 3217904-3217967 distance 8
lbn 20-75 blkno 3251816-3252263 distance 33848
lbn 76-83 blkno 3252368-3252431 distance 104
lbn 84-91 blkno 3252464-3252527 distance 32
lbn 92-852 blkno 3252896-3258983 distance 368
Each contiguous range of blocks is printed on a line.
The distance metric is the size of the gap from the end of the
previous set of blocks to the beginning of the next set of blocks.
Short distances are desirable.
qemu defaults to 128 MiB of RAM, which has been found to not necessarily be
enough for booting the system, at least on amd64 and armv7
Add a sensible -m 512 to the examples so that they'll work out of the box
in the general case.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D14234
only installed on arm and sparc64.
It is the only bits that keeps us having libreadline in base
The rest of gdb can be switched to libedit and will be in another
commit
Print a qemu line to a shell script to ease testing each image
Start to support multiple architectures (still very green)
Create /etc/rc that echos success and halts the system for better
automation (also include halt)
Create /etc/fstab on a per-boot type to test loader's passing root
to kernel.
This lets me run a test, connect to it with telnet and get either a
timeout, or a report of success.
Sponsored by: Netflix
interactive console rather than the video port. qemu has issues with X
on my mac at the moment and this is the easiest path forward.
Sponsored by: Netflix
boot images for x86. This will be enhanced to generate all the other
images (u-boot, powerpc CHRP, etc).
At the moment, it's only generating three of them. zfs+gpt+legacy
works with qemu:
qemu-system-x86_64 --drive file=${file},format=raw -serial telnet::4444,server
but the ufs ones still have issues I'm tracking down.
These images are the boot blocks, /boot/loader, a kernel, maybe a
couple of modules, /sbin/init, /bin/sh, /libexec/ld-elf.so, libc.so,
libedit and libncursesw. This is just enough to get to single user. At
the moment, these come from the host system, but should come from
OBJTOP.
At the moment, this requires root to build since the zfs tools require
it (and GELI will too when we add support for that).
Sponsored by: Netflix
this will be installed into /usr/sbin, but for now it's just used for
the boot loader regression script. It's still a bit green, and likely
will get edge cases wrong still. It's also x86 centric at the moment,
but will be enhanced shortly for u-boot, CHRP PowerPC and other
methods.
Sponsored by: Netflix
changes to the packaging part of nanobsd more easily, or experiment
with the image contents w/o regenerating a whole new image tree. This
can save minutes when you don't need to do the installworld /
installkernel, etc.
Sponsored by: Netflix
limitations in mkimg we're still not quite to where I'd like to be
(I'd like to put s3 first on the disk, then s1, but mkimg won't allow
that currently). However, the resulting image now boots with qemu using:
qemu-system-x86_64 -hdd $file -serial telnet::4444,server -nographic
We'll need tweaks to create a specialized /etc/rc.d/growfs that can
create a properly grown image for either the simple or ping-pong
cases, but that will be later. Switched to pure serial console (-h)
instead of video or serial (-P) since that fits this usecase better.
Sponsored by: Netflix