the actual code. Both use a ";" (not a ",") to delimit entries.
PR: 39679
Submitted by: Cyrille Lefevre <cyrille.lefevre@laposte.net>
MFC after: 3 days
Add definition of COMPILER_DEPENDENT_INT64 and also
fix definition of COMPILER_DEPENDENT_UINT64.
Pointed-out by: Michael Nottebrock <michaelnottebrock@gmx.net>
filesystem expands the inode to 256 bytes to make space for 64-bit
block pointers. It also adds a file-creation time field, an ability
to use jumbo blocks per inode to allow extent like pointer density,
and space for extended attributes (up to twice the filesystem block
size worth of attributes, e.g., on a 16K filesystem, there is space
for 32K of attributes). UFS2 fully supports and runs existing UFS1
filesystems. New filesystems built using newfs can be built in either
UFS1 or UFS2 format using the -O option. In this commit UFS1 is
the default format, so if you want to build UFS2 format filesystems,
you must specify -O 2. This default will be changed to UFS2 when
UFS2 proves itself to be stable. In this commit the boot code for
reading UFS2 filesystems is not compiled (see /sys/boot/common/ufsread.c)
as there is insufficient space in the boot block. Once the size of the
boot block is increased, this code can be defined.
Things to note: the definition of SBSIZE has changed to SBLOCKSIZE.
The header file <ufs/ufs/dinode.h> must be included before
<ufs/ffs/fs.h> so as to get the definitions of ufs2_daddr_t and
ufs_lbn_t.
Still TODO:
Verify that the first level bootstraps work for all the architectures.
Convert the utility ffsinfo to understand UFS2 and test growfs.
Add support for the extended attribute storage. Update soft updates
to ensure integrity of extended attribute storage. Switch the
current extended attribute interfaces to use the extended attribute
storage. Add the extent like functionality (framework is there,
but is currently never used).
Sponsored by: DARPA & NAI Labs.
Reviewed by: Poul-Henning Kamp <phk@freebsd.org>
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)
- Don't include ia64_cpu.h and cpu.h
- Guard definitions by _NO_NAMESPACE_POLLUTION
- Move definition of KERNBASE to vmparam.h
o Move definitions of IA64_RR_{BASE|MASK} to vmparam.h
o Move definitions of IA64_PHYS_TO_RR{6|7} to vmparam.h
o While here, remove some left-over Alpha references.
Get rid of the INTERNALSTATICLIB knob and just use plain INTERNALLIB.
INTERNALLIB now means to build static library only and don't install
anything. Added a NOINSTALLLIB knob for libpam/modules. To not
build any library at all, just do not set LIB.
default of -fguess-branch-probablility causes time optimizations (?)
like rewriting `if (foo) x++;' as
`if (!foo) goto forth; back: ; ...; forth: x++; goto back;". This is
pessimizes space especially well on i386's because one short branch
gets converted to 2 long ones.
Removed -fno-align-foo since it is implied by -Os. Previous commit
messages seem to have overstated the new alignment bugs in gcc. The
only case that affects boot2 is that -fno-align-functions (or
equivalently -falign-functions=1) actually gives -falign-functions=2.
This is caused by FUNCTION_BOUNDARY being 2 (bytes) instead of 1.
The default case where the optimization level is 1 and no alignment
options are given is more broken. All alignments are minimal, modulo
the bug in FUNCTION_BOUNDARY. This is caused by toplev.c setting
defaults too early.
Some hacks in previous commits ar not needed now, but may as well be
kept until gcc is fixed. The previous on in the Makefile saved 96
bytes of text due to the wrong FUNCTION_BOUNDARY and 32 bytes of data
due to unrelated bloat in the alignment of large objects. There aren't
even any options to control alignment of data.
to 4 bytes free. I removed a printf (the Keyboard yes/no) since it is of
marginal value and sed'ed the generated asm output to remove the unwanted
aligns. There's probably a better way to gain a few extra bytes than
losing the printf. Shortening strings is probably a better option but this
should get us over the hurdle.
than the first one on a controller, and work for secondary
controllers.
Due to the prom not having nodes for each disk, but a catch-all one,
we have to iterate over each device, trying to open it to determine
whether it is actually present.
Since probing this way takese some time (and spews some spurious
warnings), it should maybe be short-circuited if we use the
device we were booted from.
Implement lazy device probing, and correct slice/partiniton
handling in the ofwd_open() code. With this, I can now actually boot
a kernel from disk, and the loader does not create unnecessary
delays.
Submitted by: tmm
- Axe -fdata-sections as turning it on or off makes no difference. If
it did make a difference it would serve to bloat boot2 even further with
extra padding.
- Axe -fforce-addr. This gets us 32 bytes so we are down to only being
64-bytes over.
We still can't compile this with gcc 3.1. The problem seems to be that
the -fno-align-foo options don't actually work. Comparing the new and
old output it turns out that gcc is 4-byte padding all the functions and
labels and what not despite the passed in arguments thus adding the
unfortunate bloat to boot2.
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
o We don't expect the PLT relocations to follow the .rela section
anymore. We still assume that PLT relocations are long formed,
o Document register usage,
o Improve ILP,
o Fix the FPTR relocation by creating unique OPDs per function.
Comparing functions is valid now,
o The IPLT relocation naturally handles the addend. Deal with it.
We ignore the addend for FPTR relocations for now. It's not at
all clear what it means anyway.
Fix ABI misinterpretation:
o For Elf_Rela relocations, the addend is explicit and should not
be loaded from the memory address we're relocating. Only do that
for Elf_Rel relocations (ie the short form).
o DIR64LSB is not the same as REL64LSB. DIR64LSB applies to a
symbol (S+A), whereas REL64LSB applies to the base address (BD+A),
up the module_path string, we would walk one past the end of the buffer.
This hurting ia64 originally, but it was probably also happening on i386
occasionally as well. The effects were usually harmless, it would add
bogus "binary" search directories to the places it actually looked for
files.
the S_IFREG bit for regular files. This caused the path search code to
skip it when it finally did find the kernel (after the common/module.c
buffer overrun bug was fixed)
detects and uses the gas section merge support. As a result, a whole bunch
of new sections arrive, including .rodata.str1.8, which was not included
in our custom ldscript.ia64. The result was a loader binary that EFI
rejected.
While here, collect the loader shell commands linker set and include it
in the data area rather than having its own section.
/boot/loader.efi was the last holdout for having a 100% self built ia64
system.
