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.
In fact, these variable are set as environment variables since we run
"make TARGET=xxx TARGET_ARCH=xxx"; TARGET and TARGET_ARCH are declared
in the command line arguments. However, if you are not make(1) guy,
it is hard to understand that TARGET/TARGET_ARCH are appropriately set
in a chroot environment (as environment variables).
Now, the only environment variable need to be set explicitly is 'PATH'.
If we set PATH in /mk script, we can make pristine sandbox for release
build (i.e., "env -i /usr/sbin/chroot ${CHROOT} /mk" will work).
Valuable comments about this issue from: ru
Tested on (virtually): snapshots.jp.FreeBSD.org
MFC after: 2 weeks
create a link to man.cgi with a manpath for 5-current. Following this
link gives a "Sorry, no data found for `labpc(4)'". Instead, simply
write labpc(4) without any markup (for which pkg_update(1) is prior art)
Remove some whitespace at EOL while I'm here.
Discussed with an okayed by: bmah
Just update the 'original revision' markers of some files where the last
update of the english version has no impact on the translated version
(spelling checks are a premium cause of this) except making it harder
to find the changes that still need to be translated/comitted.
