Following a suggestion by Ruslan, the initial creation of the
includes and libraries (and build tools) is now done by
invoking "make buildworld" (with -DPICOBSD which eventually will
limit the amount of stuff built with a 2-line change in Makefile.inc1).
The correct environment is then used for subsequent builds.
Also remove write_mfs_in_kernel.c in favour of using dd
All the above is conditional on __FreeBSD_version, as the previous
method still worked for versions earlier than 500035, and I am
unsure on how the "new" method works for earlier versions.
Finally, note that the crunch.conf files need some work because
some libraries (e.g. gmd) have gone away from the base installation.
different architectures may choose to use different default values
for CFLAGS, for example. (It was added in rev. 1.200 as a measure
to make boot images fit the floppies, and was never reverted.)
Changed release notes: KSE (rewrite and status update), Binutils
2.12.1 (20020622 snapshot).
MFCs noted: libpcap-0.7.1, tcpdump-3.7.1, OpenSSH through 3.4p1.
Also retroactively note some OpenSSH items as MFC-ed and historic.
I'm not sure when these were merged, but I'm pretty sure it was a long
time ago.
no longer fits 1.44M but...
Moved vx(4) and all miibus consumers (including miibus) out
from kern.flp to mfsroot.flp. This leaves 9K of the free
space for kern.flp.
pam_ksu(8), uuidgen(1).
Updated release notes: libpcap-0.7.1, tcpdump-3.7.1.
Also do some markup fixes to recently-added items so that they don't
try to use entities for manpages that have been removed, in the spirit
of rev. 1.359.
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>
the size of the rendered release notes. By default, any element with
a role="historic" attribute won't get rendered in the output unless
the INCLUDE_HISTORIC Makefile variable is defined.
the second buildworld environment is fully isolated from parent's
environment variables.
Tested virtually on: snapshots.jp.FreeBSD.org
Approved by: arch@ (silently)
MFC after: 2 weeks
as of 4.6-RELEASE (or earlier). This commit shouldn't have any immediate
effect, but we'll eventually use some stylesheet magic to remove
the historic release notes from the output stream. This will have
the effect of making the 5.0-RELEASE release notes contain material
only relevent to -CURRENT *or* recently MFC-ed to 4-STABLE.
The stylesheet fixes will follow later, once I work out a couple more
details. I wanted to get this commit done now, before anything gets
MFC-ed in the post-4.6 world (so we don't need to go back later and
figure this out).
If a historic release note gets modified, it may very well be
appropriate to remove its historic attribute.
