common code, the non-trivial part is #ifdef'ed and only executes when
loading amd64 kernels. The rest is trivial but needed for the the amd64
case. (Two variables changed from char ** to Elf_Addr).
Approved by: re (amd64 "low-risk" stuff)
things over floppy size limits, I can exclude it for release builds or
something like that. Most of the changes are to get the load_elf.c file
into a seperate elf32_ or elf64_ namespace so that you can have two
ELF loaders present at once. Note that for 64 bit kernels, it actually
starts up the kernel already in 64 bit mode with paging enabled. This
is really easy because we have a known minimum feature set.
Of note is that for amd64, we have to pass in the bios int 15 0xe821
memory map because once in long mode, you absolutely cannot make VM86
calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader
metadata startup, just like sparc64 and powerpc. Much of the
infrastructure to support this was adapted from sparc64.
* AcpiOsDerivePciId(): finds a bus number, given the slot/func and the
acpi parse tree.
* AcpiOsPredefinedOverride(): use the sysctl hw.acpi.os_name to
override the value for _OS.
Ideas from: takawata, jhb
Reviewed by: takawata, marcel
Tested on: i386, ia64
Move the remaining bits of <sys/diskslice.h> to <i386/include/bootinfo.h>
Move i386/pc98 specific bits from <sys/reboot.h> to
<i386/include/bootinfo.h> as well.
Adjust includes in sys/boot accordingly.
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)
introduce a preprocessor define for it. The larger block size
significantly speeds up the loading of the kernel.
Submitted by: Arun Sharma <arun.sharma@intel.com>
and instead add platform, firmware and EFI stubs to the loader.
The net effect of this change is that besides a special console and
disk driver, the kernel has no knowledge of the simulator. This has
the following advantages:
o Simulator support is much harder to break,
o It's easier to make use of more feature complete simulators.
This would only need a change in the simulator specific loader,
o Running SMP kernels within the simulator. Note that ski at this
time does not simulate IPIs, so there's no way to start APs.
The platform, firmware and EFI stubs describe the following hardware:
o 4 CPU Itanium,
o 128 MB RAM within the 4GB address space,
o 64 MB RAM above the 4GB address space.
NOTE: The stubs in the skiloader describe a machine that should in
parts be defined by the simulator. Things like processor interrupt
block and AP wakeup vector cannot be choosen at random because they
require interpretation by the simulator. Currently the simulator is
ignorant of this.
This change introduces an unofficial SSC call SSC_SAL_SET_VECTORS
which is ignored by the simulator.
Tested with: ski (version 0.943 for linux)
o Revision 1.38 introduced the -n flag. It conflicted with the
RB_BOOTINFO flag, so was in effect always on. Change the -n flag to
be bit 0x1c instead of 0x1f. This also had the consequence that a mal-formed
/boot.config would render the system unbootable because the user was
unable to enter anything at all on the command line.
o Remove the initialization of opt to be RB_BOOTINFO since we filter that bit
out and do not otherwise use it.
Reviewed by: jhb
MFC after: 3 days
