Murry Stokley of FreeBSD Mall is one of the FreeBSD release
engineers. In this talk he told about FreeBSD development,
organization and what is new and cool in FreeBSD 5.0.
Development and release management
Everything is on CVS
There is a current branch and a stable branch. Material from the
current branch gets merged back into the stable branch when they have
gotten enough testing.
Over the last 12 months 160 people have committed code directly via
cvs to the FreeBSD kernel. Non commiters are welcome to submit patches
via the gnats bug tracking system.
FreeBSD is highly organized with elected leadership, developer
documentation, release engineering, core team.
Tinderbox environments constantly test the current release.
Release 4.x remains supported in the foreseeable future as most
FreeBSD sites have very high stability requirements.
New Features In 5.0
Support for kernel scheduled entities which leads to better threads
Device file system
Bluetooth and Firewire support
Mandatory Access Control
UFS2 with bigger inodes to store extended attributes
GEOM - modular disk I/O transformation framework
Device monitoring daemon devd to manage pcmcia and other plugable devices
Soft Updates (fs enhancement) with snapshots and background fsck
No more perl dependency in the base system
New platforms: ia64 and sparc64
More information is on (www.freebsd.org ...)
by H. Peter Alvin of Transmeta
As the Linux kernel developed, the root file system became more
important and had to be able to live in more and more different
places, like configurable locations on the disk or even on the
network. Eventually even in RAM as initrd entered the scene. This
caused all sorts of special cases needing handling to support all
these variants. And all this is happening inside the kernel which is
tough for development as testing is really painful. So the ideal case
would be to be able to organize the booting process in user space.
The solution is to have a virtual root for the system, called rootfs
using ramfs code. As the kernel starts, / is rootfs and the actual
root filesystem becomes a simple overlay mount. This means that it is
possible to use an initial ram disk and get rid of it later. As the
kernel threads live in their own world (rootfs).
To simplify matters further, initrd gets replaced with initialramfs
which is populated by loading one or several cpio archives. The cpio
archives can come from the disk, from the net or even be compiled into
the kernel itself. They provide the files required in early user
space. To allow initialramfs to be small and still provide a useful
environment, a special stripped down C library called klibc was
developed to provide library code for this case.
Programming in this environment is almost as simple as normal
userspace programming. Malloc works as expected, file and socket
handling is there. Still there are restrictions, as all the rest of the
system is not up yet. STDIO is available but it is very slow
especially for reading, as klibc does not implement buffering to save
space.
Candidates for early Userspace
With this infrastructure the possibilities become endless. The following
candidates for early user space come to mind:
Partition detection
Determining the root filesystem type
Network booting
Caveat
Note that this is very much an ongoing development and only available
in 2.5.x. (www.kernel.org ...) has more
information.
