Scott Long újra életrehívta a korábbi FreeBSD helyzetjelentést. A megszokottól eltérően most a 2003. márciustól szeptemberig tartó időszakot dolgozta fel. Az említett időszakban kemény munka folyt a FreeBSD Projekten belül. A kemény munkának lassan be is érik a gyümölcse. A KSE nagyon sokat fejlődött a FreeBSD 5.1 release óta, lassan az alapértelmezett default szálkezelő csomag lesz a FreeBSD-n. Az AMD64 platform gyorsan tűnt fel a semmiből, és már majdnem kész. Lássuk min is dolgoztak a fejlesztők az elmúlt hónapokban:
Az értékelésben szóba kerül a bluetooth stack, az ACPI támogatás, az AMD64 port, az ATAPI/CAM, a binárisok biztonsági frissítése, a FreeBSD lefordítása az Intel C fordítójával (icc), a kriptografikus támogatás, a device_t lockolás, a diszk I/O, a dinamikusan linkel root támogatás, a FreeBSD Java projekt, a FreeBSD port monitorozó rendszer, a FreeBSD/ia64 port, a jpman projekt, a KDE FreeBSD projekt, a kgi4BSD státusza, a KSE, a hálózati alrendszer lockolási kérdése és teljesítménye, az OpenBSD-s pf (packet filter) portolása, a PowerPC port, a Release Engineering (RE) státusza, a "Rescue build" infrastruktúra, az uart(4), a VideoBSD, a WifiBSD, a vezetéknélküli hálózati támogatás, Wireless Networking Support.
Huh, azt hiszem nem hagytam ki semmit. Érdemes elolvasni. Scott Long levele:List: freebsd-hackers
Subject: Mar 2003 - Sep 2003 FreeBSD Status Report
From: Scott Long
Date: 2003-10-09 6:10:56
[Download message RAW]
Navigation Bar
March-September 2003 Status Report
Introduction:
The FreeBSD Bi-monthly status reports are back! In this edition, we
catch up on seven highly productive months and look forward to the end
of 2003.
As always, the FreeBSD development crew has been hard at work. Support
for the AMD64 platform quickly sprang up and is nearly complete. KSE
has improved greatly since the 5.1 release and will soon become the
default threading package in FreeBSD. Many other projects are in the
works to improve performance, enhance the user experience, and expand
FreeBSD into new areas. Take a look below at the impressive summary of
work!
Scott Long, Robert Watson
* Bluetooth stack for FreeBSD (Netgraph implementation)
* ACPI Status Report
* AMD64 Porting
* ATAPI/CAM Status Report
* Binary security updates for FreeBSD
* bsd.java.mk version 2.0
* Compile FreeBSD with Intels C compiler (icc)
* Cryptographic Support
* Device_t locking
* Disk I/O
* Dynamically Linked Root Support
* FreeBSD Java Project
* FreeBSD ports monitoring system
* FreeBSD/ia64
* jpman project
* KDE FreeBSD Project
* kgi4BSD Status Report
* KSE
* Network Subsystem Locking and Performance
* Porting OpenBSD's pf
* PowerPC Port
* Release Engineering Status
* Rescue build infrastructure
* uart(4)
* VideoBSD
* WifiBSD Status Report
* Wireless Networking Support
Bluetooth stack for FreeBSD (Netgraph implementation)
URL: http://www.geocities.com/m_evmenkin/
URL: http://bluez.sf.net
URL: http://sourceforge.net/projects/openobex/
Contact: Maksim Yevmenkin
I'm very pleased to announce that another release is available for
download at
http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030908.tar.gz. I have
also prepared patch for the FreeBSD source tree. The patch was
submitted for review to the committers.
Fixed few bugs in kernel modules. The ng_hci(4) and ng_l2cap(4)
modules were changed to fix issue with Netgraph timeouts. The
ng_ubt(4) module was changed to fix compilation issue on -current.
Improved user-space utilities. Implemented new libsdp(3). Added new
sdpcontrol(8) utility. The rfcomm_sppd(1), rfcomm_pppd(8) and
obexapp(1) were changed and now can obtain RFCOMM channel via SDP from
the server. The hccontorol(8) utility now has four new commands. The
hcsecd(8) daemon now saves link keys on the disk.
I've been recently contacted by few individuals who whould like to
port current FreeBSD Bluetooth code to other BSD systems (OpenBSD and
NetBSD). The work is slowly progressing towards un-Netgraph'ing
current code. In the mean time Netgraph version will be the primary
supported version of the code.
_________________________________________________________________
ACPI Status Report
URL: http://www.root.org/~nate/freebsd/
Contact: Nate Lawson
Work is continuing on updating ACPI with new features as well as
bugfixing. A new embedded controller driver was written in July with
support for the ACPI 2.0 ECDT as well as more robust polling support.
Also, a buffer overflow in the ACPICA resource list handling that
caused panics for some users was fixed. Marcel helped get acpidump(8)
tested and basically working on ia64.
Upcoming work includes integrating ACPI notifies with devd(8),
committing user-submitted drivers for ASUS and Toshiba hotkeys, Cx
processor sleep states (so my laptop doesn't burn my lap), and power
resource support for intelligently powering down unused or idle
devices.
Users who have problems with ACPI are encouraged to submit a PR and
email its number to acpi-jp@jp.freebsd.org. Bug reports of panics or
crashes have first priority and non-working features or missing
devices (except suspend/resume problems) second. Reports of failed
suspend/resume should NOT be submitted as PRs at this time due to most
of them being a result of incomplete device support that is being
addressed. However, feel free to mail them to the list as any
information is helpful.
_________________________________________________________________
AMD64 Porting
Contact: Peter Wemm
The last known bug that prevented AMD64 machines completing a full
release has been fixed - one single character error that caused
ghostscript to crash during rendering diagrams. SMP work is nearing
completion and should be committed within the next few days. The SMP
code uses the ACPI MADT table based on John Baldwin's work-in-progress
there for i386. We need to spend some time on low level optimization
because there are several suboptimal places that have been ignored for
simplicity, context switching in particular. MTRR support has been
committed and XFree86 can use it. cvsup now works but the ezm3 port
has not been updated yet. The default data segment size limit is 8GB
instead of 512M, and the (primitive) i386 binary emulation support
knows how to lower the rlimits for executing 32 bit binaries.
Notable things missing still: Hardware debug register support needs to
be written; gdb is still being done as an external set of patches
relative to the not-yet-released FSF gdb tree; DDB does not
disassemble properly; DDB cannot do stack traces without
-fno-omit-frame-pointer - a stack unwinder is needed; i386 and amd64
linux binary emulation is needed, and the i386 FreeBSD binary
emulation still needs work - removing the stackgap code in particular.
The platform in general is very reliable although a couple of problems
have been reported over the last week. One appears to be a stuck
interrupt, but all that code has been redone for SMP support.
_________________________________________________________________
ATAPI/CAM Status Report
Contact: Thomas Quinot
With the introduction of ATAng, some users of ATAPI/CAM have
experienced various problems. These have been mostly tracked down to
issues in the new ATA code, as well as two long-standing problems in
portions of the CAM layer that are rarely exercised with "real" SCSI
SIMs. This has also been an occasion to cleanup ATAPI/CAM to make it
more robust, and to enable DMA for devices accessed through it,
resulting in improved performances.
_________________________________________________________________
Binary security updates for FreeBSD
URL: http://www.daemonology.net/freebsd-update/
Contact: Colin Percival
FreeBSD Update is a system for tracking the FreeBSD release (security)
branches. In addition to being faster and more convenient than source
updates, FreeBSD Update also requires less bandwidth and is more
secure than source updates via CVSup. However, FreeBSD Update is
limited; it can only update files which were installed from an
official RELEASE image and not recompiled locally. Right now I'm
publishing binary updates for 4.7-RELEASE and 4.8-RELEASE; since my
only available box takes 3.5 hours to buildworld, I don't have enough
resources to do any more than that.
In the near future, I'd like to: Find someone who is willing to donate
a faster buildbox; start building updates for other releases (at a
minimum, for all "supported" FreeBSD releases); add warnings if a file
would have been updated but can't be updated because it was recompiled
locally; add code to compare the local system against a list of
"valid" MD5 hashes for intrusion detection purposes; and add support
for cross-signing, whereby several machines could build updates
independently to protect against buildbox compromise.
_________________________________________________________________
bsd.java.mk version 2.0
URL: http://www.esil.univ-mrs.fr/~hquiroz/freebsd/bsd.java.mk-2.0.html
Contact: Ernst De Haan
Contact: Herve Quiroz
The FreeBSD Java community has started an effort to improve the
current framework for Java-based ports. The main objective is the
automation of JDK/JRE build and run dependency checking.
The original version was aimed to ease the life of porters. Although
it has proved to be useful and reliable to a great extend, we are
currently working on a new version. We intend to reach a high degree
of flexibility to cope with the recent increase of available JDK/JRE
flavors. Furthermore, the new version will be easier to maintain,
which means improved reliability, and hopefully more frequent updates.
_________________________________________________________________
Compile FreeBSD with Intels C compiler (icc)
URL: http://www.Leidinger.net/FreeBSD/
Contact: Alexander Leidinger
Since I ported icc to FreeBSD I wanted to build FreeBSD with icc. Now
with icc 7.1 (and some patches) it is possible. There are still some
bugs, e.g. NFS doesn't work with an icc compiled kernel, IP seems to
be fragile, and some advanced optimizations trigger an ICE (Intel is
working on it). At the moment I'm waiting for our admins to install
icc on the FreeBSD cluster (we got a commercial license from Intel, so
we are allowed to distribute binaries which are compiled with icc),
after that I will try to convince some people with more knowledge of
the IP and NFS parts of the kernel to debug the remaining problems.
When the icc compiled kernel seems to work mostly bugfree the userland
will get the porting focus. Interested people may try to do a build of
the ports tree with icc independently from the status of the porting
of the userland... if this happens at the FreeBSD cluster, we would
also be allowed to distribute the binaries.
Benefits include: another set of compiler errors (debugging help),
more portable source, and code which is better optimized for a P4 (gcc
has some drawbacks in this area)
_________________________________________________________________
Cryptographic Support
Contact: Sam Leffler
Support for several new crypto devices was added. The SafeNet 1141 is
a medium performance part that is not yet available on retail
products. The Hifn 7955 and 7956 parts are starting to appear on
retail products that should be available by the end of the year. Both
devices support AES encryption. Support for public key operations for
the SafeNet devices was recently done for OpenBSD and will be
backported. Public key support for the Hifn parts is planned.
A paper about the performance work done on the cryptographic subsystem
was presented at the Usenix BSDCon 2003 conference and received the
best paper award.
NetBSD recently imported the cryptographic subsystem.
_________________________________________________________________
Device_t locking
Contact: Warner Losh
A number of races have been identified in locking device_t. Most of
the races have been identified in making device_t have to do with how
drivers are written. Efforts are underway to identify all the races,
and to contact the authors of subsystems that can help the drivers. Of
special concern is the need for the driver to ensure that all threads
are completely out of the driver code before detach() finishes. Of
additional concern is making sure that all sleepers are woken up
before certain routines are called so that other subsystems can ensure
the last condition and leave no dangling references. Locking device_t
is relatively straight forward apart from these issues. Towards the
end of proper locking, sample strawmen drivers are being used to work
out what, exactly proper is. Once these issues are all known and
documented in the code, efforts will be made to update relevant
documentation in the tree. There are many problems with driver locking
that has been done to date, but until we nail down how to write a
driver in current, it will be premature to contact specific driver
writers with specific concerns.
_________________________________________________________________
Disk I/O
Contact: Poul-Henning Kamp
The following items are in progress in the Disk I/O area: Turn
scsi_cd.c into a GEOM driver. (Patch out for review). Turn atapi-cd.c
into a GEOM driver. Turn fd.c into a GEOM driver. Move softupdates and
snapshot processing from SPECFS to UFS/FFS. Move userland access to
device drivers out of vnodes.
Once these preliminaries are dealt with, scatter/gather and
mapped/unmapped support will be added to struct bio/GEOM.
_________________________________________________________________
Dynamically Linked Root Support
Contact: Gordon Tetlow
Support for a dynamically linked /bin and /sbin has been committed,
although it is not turned on by default. Adventurous users can try it
out by building /bin and /sbin using the WITH_DYNAMICROOT make flag.
More testing is needed to determine if this is going to be default for
5.2-RELEASE. If anyone would like to benchmark worldstones with and
without dynamically linked /bin and /sbin, please feel free to do so
and submit the results.
_________________________________________________________________
FreeBSD Java Project
URL: http://www.freebsd.org/java/
Contact: Greg Lewis
The BSD Java Porting Team has recently reached an exciting milestone
with the release of the first "Diablo" JDK and JRE courtesy of the
FreeBSD Foundation. The release of Diablo Caffe and Diablo Latte 1.3.1
was the first binary release of a native FreeBSD JDK since 1.1.8 and
marks an important step forward in FreeBSD Java support.
The team is continuing development work, with a focus on achieving a
compliant JDK 1.4 release in the near future.
_________________________________________________________________
FreeBSD ports monitoring system
URL: http://lonesome.dyndns.org:4802/bento/errorlogs/index.html
Contact: Mark Linimon
Several months ago, I took it upon myself to to try present the
information contained on the bento build cluster to be presented in a
more user-friendly fashion; that is, to be browsed by error type, by
maintainer, and so forth. An early addition was code to attempt to
classify ports PRs by either "existing port" (after assiging the most
likely category and portname); "new port"; "framework" (e.g.
bsd.port.mk changes); and "unknown". Various columns about the ports
PRs were added to the reports.
The initial intent of this was to make life easier for ports
maintainers; however, the "general" reports are also useful to anyone
who just wants to, e.g., find out if a particular port is working on
their particular architecture and OS combination before downloading
it. Those with that general interest should start with the overview of
one port.
_________________________________________________________________
FreeBSD/ia64
URL: http://www.FreeBSD.org/platforms/ia64/index.html
Contact: Marcel Moolenaar
Much has happened since the last bi-monthly report, which was more
than half a year ago. FreeBSD 5.0 and FreeBSD 5.1 have been released
for example. With FreeBSD 5.2 approaching quickly, we're not going to
look back too far when it comes to our achievements. There's too much
ahead of us...
Two milestones have been reached after FreeBSD 5.1. The first is the
ability to support both Intel and HP machines with sources in CVS.
This due to a whole new driver for serial ports, or UARTs.
Unfortunately this still implies that syscons is not configured.
That's another task for another time, but keep an eye on
KGI/FreeBSD... The second milestone is the completion of KSE support.
Both M:N and 1:1 threading is functional on ia64 and the old libc_r
library has been obsoleted. Testing has shown that KSE (i.e. M:N) may
well become the default threading model. It's looking good.
The ABI hasn't changed after 5.1 and the expectation is that it won't
change much. This means that we can think about becoming a tier 1
platform. This also means we need gdb(1) support. Work on it has been
started but the road is bumpy and long. Kernel stability also has
improved significantly and we typically have one kernel panic
remaining: VM fault on no fault entry. This will be addressed with the
long awaited PMAP overhaul (see below).
Most work for FreeBSD 5.2 will be "sharpening the saw". Get those
loose ends tied. This is a slight change of plan made possible by a
slip in the release schedule. The 5.2 release is not going to be the
start of the -stable branch; it has been moved to 5.3. So, we use the
extra time to prepare the ground for 5.3.
The planned PMAP overhaul will probably be finished after 5.2. This
should address all known issues with SMP and fix those last panics. As
a side-effect, major performance improvements can be expected. More
news about this in the next status reports.
_________________________________________________________________
jpman project
URL: http://www.jp.FreeBSD.org/man-jp/
URL:
ftp://daemon.jp.FreeBSD.org/pub/FreeBSD-jp/man-jp/packages-5.1.0/ja-ma
n-doc-5.1.tbz
Contact: Kazuo Horikawa
We have released Japanese translation of 5.1-RELEASE online manual
pages on June 10.
_________________________________________________________________
KDE FreeBSD Project
URL: http://freebsd.kde.org/
Contact: KDE-FreeBSD Mailinglist
The FreeBSD ports were updated to KDE 3.1.4, another bug- and
security-fixes release. With this update, the QT port was updated to
version 3.2. Both will be included in FreeBSD 4.9. Significant work
was spent to fix KDE on FreeBSD-CURRENT after the removal of the gcc
-pthread Option. Automatic package builds from KDE CVS continued to
ensure and improve the quality of the upcoming KDE 3.2 release.
Future: Work is in progress to setup a new server for hosting the
KDE-FreeBSD Website, Repository and another KDE CVS mirror. With help
from Marcel Moolenaar the project will try to make KDE compile and
working on the Intel IA64. And last but not least efforts are being
made to fix the currently broken kdesu program.
_________________________________________________________________
kgi4BSD Status Report
URL: http://www.FreeBSD.org/~nsouch/kgi4BSD
Contact: Nicholas Souchu
A lot of work done since last report: site reworked completly (see new
URL), console design with console message in text or graphic modes
implemented, implementation of a compatibility layer to compile Linux
fbdev drivers with more or less changes in the original driver
(experimental).
Except some memory allocation bugs, X (XGGI based on XFree 3.3.6) is
now working with the same driver as the console. A basic terminal has
now to be implemented.
Volonteers are welcome to the project...
_________________________________________________________________
KSE
URL: http://www.freebsd.org/kse/index.html
Contact: Dan Eischen
Contact: David Xu
KSE seems to be working well on x86, amd64, and ia64. The alpha
userland bits are done, but a couple of functions are unimplemented in
the kernel. For sparc64, the necessary functions are implemented in
the kernel, but the userland context switching functions need more
attention.
Since 5.1, efficient scope system threads (no upcalls when they block)
have been implemented, and KSE based pthread library can have both
POSIX scope process threads and scope system threads. It is also
possible that KSE based pthread library can implement pthread both in
1:1 and M:N mode, I know Dan has such Makefile file patch for libkse
not yet committed.
KSE program now can work under ULE scheduler, its efficient should be
improved under the new scheduler in future. BSD scheduler is still the
best scheduler for current KSE implement.
_________________________________________________________________
Network Subsystem Locking and Performance
Contact: Sam Leffler
The purpose of this project is to improve performance of the network
subsystem. A major part of this work is to complete the locking of the
networking subsystem so that it no longer depends on the "Giant lock"
for proper operation. Removing the use of Giant will improve
performance and permit multiple instances of the network stack to
operate concurrently on multiprocessor systems.
This project started in August. The emphasis has been on locking the
"lower half" of the networking code so that packet forwarding through
the IPv4 path can operate without the Giant lock as part of the 5.2
release. To this end locking was added to several network interface
drivers and much of the "middleware" code in the network was locked
(e.g. ipfw, dummynet, then routing table, multicast routing support,
etc). Work towards this goal is still ongoing but should be ready for
5.2. A variety of test systems have been running for several months
without the Giant lock in the network drivers and IP layer.
Past the 5.2 release Giant will be removed from the "upper half" of
the network subsystem and the socket layer. Once this is done the plan
is to measure and improve performance (though some work of this sort
is always happening). The ultimate goal is a system that performs at
least as well as 4.x for normal use on uniprocessor systems. On
multiprocessor systems we expect to see significantly better
performance than 4.x due to greater concurrency and reduced latency.
_________________________________________________________________
Porting OpenBSD's pf
URL: http://pf4freebsd.love2party.net
URL: http://www.benzedrine.cx/pf.html
URL: http://openbsd.org/faq/pf/index.html
Contact: Max Laier
Contact: Pyun YongHyeon
The project started this spring and released version 1.0 with a port
installation (security/pf) in may 2003. Version 2.0 is on the doorstep
as OpenBSD 3.4 will be released. Due to the porting efforts we were
able to reveal some bugs in the OpenBSD code and provided locking for
the PFIL_HOOKS, which we utilize. Tarball installation of a loadable
kernel module for testing can be found on the project homepage, a
patchset is in the making.
PF was started at OpenBSD as a substitute for ipfilter and provides
the same function set. However, in the two years it exists now, it has
gained many superior features that no other packet filter has. For a
impression take a look at the pf FAQ.
We hope to be eventually integrated into the base system. Before that
we have to resolve some issues with tcpdump and kame.
_________________________________________________________________
PowerPC Port
Contact: Peter Grehan
Work has restarted after a hiatus. Current focus is on getting
loadable modules working, NEWBUSing the NetBSD dbdma code, and
completing the BMAC ethernet driver.
There is a huge amount of work to do. Volunteers more than welcome!
_________________________________________________________________
Release Engineering Status
Contact: Scott Long
The release of 4.9 is just around the corner and offers Physical
Address Extensions (PAE) for x86 along with the same world-class
stability and performance that is expected from the 4-STABLE series.
As always, don't forget to purchase a copy of the CD set from your
favorite FreeBSD vendor.
FreeBSD 5.1 was released in June and offered vastly improved stability
over 5.0 along with a working implementation of Kernel Scheduled
Entities, allowing for true multithreading of applications across
multiple CPUs. FreeBSD 5.2 will be released by the end of 2003 and
will focus on improved network and overall performance.
_________________________________________________________________
Rescue build infrastructure
Contact: Gordon Tetlow
Contact: Tim Kientzle
The rescue build infrastructure has been committed. There is one known
issue with make using both the '-s' and '-j' flags that appears to be
a bug in make. Anyone interested in tracking down should contact us.
_________________________________________________________________
uart(4)
Contact: Marcel Moolenaar
The uart(4) project was born out of the need to have a working serial
interface (i.e. an RS-232-C interface) in a legacy-free configuration
and after an unsuccessful attempt to convert sio(4). The biggest
problem with sio(4) is that it has been intertwined in many ugly ways
into the kernel's core. Conversion could not happen without breaking
something that invariably affects some group of people negatively.
With sio(4) as a good bad example and a strong desire to solve
multiple problems at once, the idea of an UART (Universal
Asynchronuous Receiver/Transmitter) device that, given its generic
name, could handle different flavors of UART hardware started to
settle firmly in the authors mind.
The biggest challenge was of course solving the problem of the
low-level console access prior to the initialization of the bus
infrastructure and still have a driver that uses the bus access
exclusively. Along the way the problem of having an UART function as
the keyboard on sparc64 was solved with the introduction of system
devices, which also encapsulated the console as a system device.
The uart(4) driver can be enhanced to support the various UART
hardware on pc98 and this is currently being worked on. Keyboard
support on sparc64 is underway as well. Plans exist for a rewrite of
the remote gdb support that uses a generic interface to allow various
drivers, including uart(4), to register itself as a communications
channel. And since uart(4) does not support multi- port cards by
itself, we likely need to either enhance puc(4) or otherwise introduce
other umbrella drivers
_________________________________________________________________
VideoBSD
URL: http://people.FreeBSD.org/~jmg/videobsd.html
Contact: John-Mark Gurney
Still in the planning stage. Working on creating an extensible
interface that is usable for both userland and kernel implementations
for device drivers. Deciding on how to interface userland implemented
device drivers with applications.
_________________________________________________________________
WifiBSD Status Report
URL: http://www.wifibsd.org
Contact: Jon Disnard
WifiBSD is a miniture version of FreeBSD for wireless applications.
Originally for the Soekris Net45xx line of main-boards, but is now
capable of being targeted to any hardware/architecture FreeBSD itself
supports. Although not feature complete, WifiBSD is expected to be
ready for 5.2-RELEASE. The design goal is to meet, or exceed, the
functionality of commercial/consumer 802.11 wireless gear. Features
that need attention (to name just a few) are: http interface, consol
menu interface, and installation. Volunters are welcome.
_________________________________________________________________
Wireless Networking Support
Contact: Sam Leffler
Numerous bugs have been fixed since the last status report (and of
course a few new ones added). Progress on improved security has been
slowed by other work. But new features and fixes are coming in from
other groups that are now sharing the code. In particular NetBSD
recently imported the revised 802.11 layer and the Linux-based MADWIFI
project is using it too (albeit in an older form). The MADWIFI users
have already contributed features such as fragmentation reassembly of
802.11 frames and improved signal monitoring. Power save polling and
an improved rate control algorothm are expected to come in from the
NetBSD folks. WPA support is still in the plans; the best estimate is
that work on that will start in January.
_________________________________________________________________
News Home | Status Reports Home
_________________________________________________________________
freebsd-questions@FreeBSD.org
Copyright © 1995-2003 the FreeBSD Project. All rights reserved.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread