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>
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.
- 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.
because the buffers we use could end up spanning a 64k boundary.
Unfortunately it causes too much bloat (228 -> 72 bytes free) to
just reinstate the old malloc() function.
Instead, define a structure that contains all 4 buffers which must
not cross 64k boundaries. We allocate a 64k-aligned instance in
main() using the magic that was in the old boot2 malloc() function.
This brings the free space down to 168 bytes, but that is still
better than it was before revision 1.35 (136 bytes).
Reported by: Mike Brancato <funnyguy@digitalsmackdown.net>
Pointy-hat to: iedowse
done with boot1 on the alpha. We use 4k buffers regardless of the
actual filesystem block size.
Remove the simple malloc() implementation, as it is no longer used.
the first sector of the emulated floppy to contain a valid MS-DOS BPB that
it can modify. Since boot1 is the first sector of boot.flp, this resulted
in the BIOS overwriting part of boot1: specifically the function used to
read in sectors from the disk.
Submitted by: Mark Peek <mark@whistle.com>
Submitted by: Doug Ambrisko <ambrisko@ambrisko.com>
PR: i386/26382
Obtained from: NetBSD, OpenBSD (the example BPB)
MFC after: 1 month
longer includes machine/elf.h.
* consumers of elf.h now use the minimalist elf header possible.
This change is motivated by Binutils 2.11.0 and too much clashing over
our base elf headers and the Binutils elf headers.
with the new binutils. Now that we have a decent assembler, all the old
m4 macros are no longer needed. Instead, straight assembly can be used
since as(1) now understands 16-bit addressing, branches, etc. Also,
several bugs have been fixed in as(1), allowing boot0.s to be further
cleaned up.
-fschedule-insns as it wasn't such a big win with 2.95 after all.
Add the *BIG* win "-mpreferred-stack-boundary=2" optimiztion submitted by
Dima. GCC 2.95 ensures the stack frame is always properly [opitimally]
aligned by surrounding every function call by code simular to
"addl $-12, %esp" / "addl $12, %esp". Here we need the reduction in space,
with speed not an issue.
Remove some printf() calls, reduce size of buffers, and abbreviate
some strings.
Hopefully the boot people will fix this spamage after the cut over to
Gcc 2.95.2 as the system compiler.
either one gives us an additional 32 bytes of additional space available
when using EGCS 1.1.2. With GCC 2.95.2 -fforce-addr gives us 12 more bytes,
and adding -fschedule-insns gives us an additional 4 bytes.
Move the relocated boot1 and arg transfer space from 0x600/0x800 to
0x700/0x900. In theory this should make no difference, apart from the fact
that Buslogic controllers happen to use a few bytes at 0x600 for some sort
of scratch space for it's int 0x13 hook (!!!), causing the machine to crash
badly when the boot2 code makes it's callbacks into boot1 for disk IO.
Submitted by: Robert Nordier <rnordier@freebsd.org>
interface. Do some general consistency fixes and space optimizations.
Use of some freed-up space to defend against possible BIOS misfeatures.
boot2: Revise disk read interface to provide for boot1 changes. Free
up space for this.
