the serial console speed (i386 and amd64 only). If the previous
stage boot loader requested a serial console (RB_SERIAL or RB_MULTIPLE)
then the default speed is determined from the current serial port
speed. Otherwise it is set to 9600 or the value of BOOT_COMCONSOLE_SPEED
at compile time.
This makes it possible to set the serial port speed once in
/boot.config and the setting will propagate to boot2, loader and
the kernel serial console.
user to interrupt autoboot process at all. Currently, even when
`autoboot_delay' is set to 0, loader(8) still allows autoboot process to be
interrupted by pressing any key on the console when the loader reads kernel
and modules from the disk. In some cases (i.e. untrusted environment) such
behaviour is highly indesirable and user should not be allowed to interfere
with the autoboot process at all.
Sponsored by: PBXpress Inc.
MFC after: 3 days
will prepend the current kernel booting... This prevents a problem of
loading /boot/kernel's modules when a different kernel has no modules,
but you left your module_load="YES" in loader.conf...
Reviewed by: dcs (minus the help part)
bootp -> BOOTP
bootp.nfsroot -> BOOTP_NFSROOT
bootp.nfsv3 -> BOOTP_NFSV3
bootp.compat -> BOOTP_COMPAT
bootp.wired_to -> BOOTP_WIRED_TO
- i.e. back out the previous commit. It's already possible to
pxeboot(8) with a GENERIC kernel.
Pointed out by: dwmalone
BOOTP -> bootp
BOOTP_NFSROOT -> bootp.nfsroot
BOOTP_NFSV3 -> bootp.nfsv3
BOOTP_COMPAT -> bootp.compat
BOOTP_WIRED_TO -> bootp.wired_to
This lets you PXE boot with a GENERIC kernel by putting this sort of thing
in loader.conf:
bootp="YES"
bootp.nfsroot="YES"
bootp.nfsv3="YES"
bootp.wired_to="bge1"
or even setting the variables manually from the OK prompt.
pf/pflog/pfsync as modules. Do not list them in NOTES or modules/Makefile
(i.e. do not connect it to any (automatic) builds - yet).
Approved by: bms(mentor)
assure backward compatibility (conditional on !BURN_BRIDGES), look it up
by its old name first, and log a warning (but accept the setting) if it
was found. If both the old and new name are defined, the new name takes
precedence.
Also export vm.kmem_size as a read-only sysctl variable; I find it hard to
tune a parameter when I don't know its default value, especially when that
default value is computed at boot time.
queue items that can be allocated by netgraph and the number of free queue
items that are cached on a private list.
Netgraph places an upper limit on the number of queue items it may allocate.
When there is a large number of netgraph messages travelling through the
system (100k/sec and more) there is a high probability, that messages get
queued at the nodes and netgraph runs out of queue items. In this case the data
flow through netgraph gets blocked. The tuneable for the number of free
items lets one trade memory for performance.
The tunables are also available as read-only sysctls.
PR: kern/47393
Reviewed by: julian
Approved by: jake (mentor)
this is called /boot/nextboot.conf. This file is required to have it's first
line be nextboot_enable="YES" for it to be read. Also, this file is
rewritten by the loader to nextboot_enable="NO"<space> after it is read.
This makes it so the file is read exactly once. Finally, the nextboot.conf
is removed shortly after the filesystems are mounted r/w.
Caution should be taken as you can shoot yourself in the foot. This is only
the loader piece. There will be a tool called nextboot(8) that will manage
the nextboot.conf file for you. It is coming shortly.
Reviewed by: dcs
Approved by: jake (mentor)
loader variable, which let users specify the root mount point
the exact way one does after booting the kernel.
Let's take this opportunity to document it...
around. If the kernel boots successfully, the record of this kernel
is erased, it is intended to be a one-shot option for testing
kernels.
This could be improved by having the loader remove the record of
the next kernel to boot, it is currently removed in /etc/rc immediately
after disks are mounted r/w.
I'd like to MFC this before the 4.6 freeze unless there is violent
objection.
Reviewed by: Several on IRC
MFC after: 4 days
This allows obtaining crash dumps from the panics occured during late stages
of kernel initialisation before system enters into single-user mode.
MFC after: 2 weeks
- Add S4BIOS sleep implementation. This will works well if MIB
hw.acpi.s4bios is set (and of course BIOS supports it and hibernation
is enabled correctly).
- Add DSDT overriding support which is submitted by takawata originally.
If loader tunable acpi_dsdt_load="YES" and DSDT file is set to
acpi_dsdt_name (default DSDT file name is /boot/acpi_dsdt.aml),
ACPI CA core loads DSDT from given file rather than BIOS memory block.
DSDT file can be generated by iasl in ports/devel/acpicatools/.
- Add new files so that we can add our proposed additional code to Intel
ACPI CA into these files temporary. They will be removed when
similar code is added into ACPI CA officially.
Load the first of the following kernels to be found:
${kernel} if ${kernel} is an absolute path
/boot/${kernel}/${kernel}
/boot/${kernel}/${bootfile}
${kernel}/${kernel}
${kernel}/${bootfile}
${kernel}
${bootfile}
The last instance of ${kernel} and ${bootfile} will be treated as a
list of semicolon separated file names, and each will be tried in turn,
from left to right.
Also, for each filename loader(8) will try filename, filename.ko,
filename.gz, filename.ko.gz, in that order, but that's not related
to this code.
This resulted in a major reorganization of the code, and much of what
was accumulating on loader.4th was rightly transfered to support.4th.
The semantics of boot-conf and boot also changed. Both will try to load
a kernel the same as above.
After a kernel was loaded, the variable module_path may get changed. Such
change will happen if the kernel was found with a directory prefix. In
that case, the module path will be set to ${directory};${module_path}.
Next, the modules are loaded as usual.
This is intended so kernel="xyzzy" in /boot/loader.conf will load
/boot/xyzzy/kernel.ko, load system modules from /boot/xyzzy/, and
load third party modules from /boot/modules or /modules. If that doesn't
work, it's a bug.
Also, fix a breakage of "boot" which was recently introduced. Boot without
any arguments would fail. No longer. Also, boot will only unload/reload
if the first argument is a path. If no argument exists or the first
argument is a flag, boot will use whatever is already loaded. I hope this
is POLA. That behavior is markedly different from that of boot-conf, which
will always unload/reload.
The semantics introduced here are experimental. Even if the code works,
we might decide this is not the prefered behavior. If you feel so, send
your feedback. (Yeah, this belongs in a HEADS UP or something, but I've
been working for the past 16 hours on this stuff, so gimme a break.)
Use Warner Losh's "hint" driver to decode ascii strings to fill the
resource table at boot time.
config(8) no longer generates an ioconf.c table - ie: the configuration
no longer has to be compiled into the kernel. You can reconfigure your
isa devices with the likes of this at loader(8) time:
set hint.ed.0.port=0x320
userconfig will be rewritten to use this style interface one day and will
move to /boot/userconfig.4th or something like that.
It is still possible to statically compile in a set of hints into a kernel
if you do not wish to use loader(8). See the "hints" directive in GENERIC
as an example.
All device wiring has been moved out of config(8). There is a set of
helper scripts (see i386/conf/gethints.pl, and the same for alpha and pc98)
that extract the 'at isa? port foo irq bar' from the old files and produces
a hints file. If you install this file as /boot/device.hints (and update
/boot/defaults/loader.conf - You can do a build/install in sys/boot) then
loader will load it automatically for you. You can also compile in the
hints directly with: hints "device.hints" as well.
There are a few things that I'm not too happy with yet. Under this scheme,
things like LINT would no longer be useful as "documentation" of settings.
I have renamed this file to 'NOTES' and stored the example hints strings
in it. However... this is not something that config(8) understands, so
there is a script that extracts the build-specific data from the
documentation file (NOTES) to produce a LINT that can be config'ed and
built. A stack of man4 pages will need updating. :-/
Also, since there is no longer a difference between 'device' and
'pseudo-device' I collapsed the two together, and the resulting 'device'
takes a 'number of units' for devices that still have it statically
allocated. eg: 'device fe 4' will compile the fe driver with NFE set
to 4. You can then set hints for 4 units (0 - 3). Also note that
'device fe0' will be interpreted as "zero units of 'fe'" which would be
bad, so there is a config warning for this. This is only needed for
old drivers that still have static limits on numbers of units.
All the statically limited drivers that I could find were marked.
Please exercise EXTREME CAUTION when transitioning!
Moral support by: phk, msmith, dfr, asmodai, imp, and others
